When Code Becomes a Cause: Reflections on the Language Wars
Microsoft’s recent decision to rebuild the TypeScript toolchain using Go has reignited a familiar debate among developers: why Go and not C#, or even TypeScript itself? For many, it seemed odd that Microsoft would bypass its own flagship language. The resulting discourse quickly devolved into a familiar refrain—”my language is better than your language”—a sentiment that’s been echoing through the programming world for decades.
The first sparks of that tribalism hit me back in the 1970s when I began programming in BASIC, a language defined by its simplicity and reliance on line numbers. At the time, the arrival of Pascal—with its lack of line numbers—was baffling. “How do you know where to GOTO?” I wondered. But soon enough, Pascal became the very foundation of my professional career, first as Turbo Pascal and later through Delphi. What began as a hobby turned into a profession, eventually leading me to a role as Delphi’s product manager.
Delphi, in its early days, was jokingly dubbed the “VB Killer”—a pointed reference to Visual Basic, the dominant force in Windows development at the time. VB’s visual design and simplicity made it immensely popular, but we Delphi advocates were convinced our language was better. We took that fight straight into VB forums, loudly proclaiming the end of Visual Basic. Unsurprisingly, VB fans weren’t too pleased. The battles that followed were more than technical—they were emotional, laced with personal insults and fierce loyalty, as if a language choice defined who we were.
Looking back, it’s almost comical how passionately we argued about tools—especially considering we had to pay for them back then. Today, most programming languages and toolchains are free and open source, yet the debates persist. Now it’s Rust vs. C++, TypeScript vs. JavaScript, or Go vs. everything else. Despite all the progress, the same flame wars smolder on. Maybe it’s just part of being human—we tie our identities to the tools we use, forgetting that, in the end, they’re just different ways of solving problems. And every generation of developers has to learn that for themselves.