There is No One True Best Programming Language (but some are still better than others)
I am no stranger to programming language controversy. I have a whole
category on my blog dedicated to explaining why Rust
is better than C++, and I’ve taken the extra step of organizing it into
an MDBook for everyone’s convenience. Most of them have
been argued about on Reddit, and a few even on Hacker News. Every single
one of them have been subject to critique, and in the process, I’ve been
exposed to every corner, every trope and tone and approach of programming
debate religious war, from the polite and well-considered
to the tiresome and repetitive all the way to the rude and non-sensical.
There are two tropes in particular that many times have been proferred to me (or rather, levered at me) about programming languages, two opposite errors that I would like to critique. I would say that I’d like to nip them in the bud, or respond to them once and for all, but I know the power of my blog is limited, so instead I’d just like to give my opinion on them, and explain why they are erroneous. Here are the errors:
- There is one best programming language.
- Every programming language has its place.
Error #1: There is one best programming language#
Some languages have fans in the original sense of fanatic. Some languages inspire a level of devotion in programmers where they forswear other programming languages with an almost religious loyalty. These fanatics truly believe that the programming language is perfect, and that no other language can so perfectly capture the structure of computing and of algorithmic reasoning – or even be acceptable in light of the existence of a perfect programming language.
Any threat to this programming monolatry is then attacked as intrinsically irrational. After all, if everyone would just do the basic and obvious step of rewriting everything in this ideal programming language, then all bugs would be fixed. Then, “the wolf also shall dwell with the lamb, and the leopard shall lie down with the kid,” everyone will be immortal, and the messiah will come… And this, of course, is insufferable to normal people, who realize that programming languages are tools, not gods.
Rust, admittedly, brings this out in people. So does Lisp, and so does Haskell. And lest you think I’m exaggerating with the religious references, someone even wrote a Haskell book entitled To Kata Haskellen Evangelion, Biblical Greek for the blasphemous and hopefully tongue-in-cheek title The Gospel according to Haskell.
I know what you’re thinking; I can hear it in my head. You’re thinking: “You’re one to talk, Jimmy! The Coded Message is a Rust blog, and worse, a Rust evangelism blog! How dare you criticize when you’re one of the worst offenders?”
Nevertheless, in spite of what you might think, I don’t think Rust is the one true programming language. I think it’s ahead of other mainstream programming languages in terms of strong typing and functional features (key word “mainstream”), and I personally enjoy working on it full time, all true. But while I am a fan, I don’t think it’s perfect, or even unique in most of the ways it’s good.
Instead, I bring up this error for the reason I promised: Because it has been levelled against me. Early on, with my first Rust post, I wrote this statement (and see if you can see why it was controversial):
If you are a systems programmer, if you are used to C and C++ and to trying to solve systems programming types of problems, Rust is magical, just like when you learned your previous favorite programming language.
If you are not, Rust is overkill for your task at hand and you shouldn’t be using it. I earnestly recommend Haskell.
This got me quite a bit of anger on Reddit. One commenter was furious that I recommended Haskell, because they had tried to learn it in the past and had a bad time. Another tried to tell me I was being stubborn because the collected testimony of the Rust Reddit hadn’t somehow managed to override my 18 years of professional programming experience and convince me that garbage collection was not a necessary thing to have in a programming language sometimes.
And the key term there is Rust Reddit: There are some people there who think everyone should be writing Rust, even people who have every reason to benefit from a garbage collector and who have nothing to gain from the strictness of a borrow checker, because they think Rust is just the absolute best possible language. And the Rust sub-reddit does what any good echo chamber does, and brings out that vibe in every Rustacean.
But the echo chamber did not get me. Although I’ve moderated my opinion some – I’ve realized that there are some times where Rust beats out GC’d languages for applications outside of my narrow definition of systems programming, if only because it is both so mainstream and so successful at bringing in modern FP features – I still hold by my fundamental point:
Sometimes, indeed probably for most programming projects, Rust is the wrong choice. Just like I wouldn’t use Excel to do systems programming, I wouldn’t use Rust to keep track of splitting expenses on a trip.
Even for “serious” programming projects (whatever that means), sometimes, you simply do need a garbage collector. Sometimes, the semantics of Rust are too deep-cut or complicated to teach to the people you need to do your programming.
Heck, sometimes even existing infrastructure or existing legacy codebases or just existing skillsets are more important than what programming language features you have. Sometimes, Rust would take a re-write. And re-writing in Rust is not a panacea, or even always a good idea.
Error #2: Every programming language has its place#
This one of course gets levelled against me far more often, especially in my Rust vs C++ debates. Most people realize programming languages are technical tools, and a skilled programmer can pick new ones up with relative ease. But some people act and talk instead as if, say, C++ programmers were an ethnic or religious group. If I call for the gradual deprecation and obsolescence of C++ in favor of Rust – while understanding that legacy code is a genuine concern that will be with us for decades – these people act as if I’m calling for crimes against humanity, saying Kumbaya-reminiscent statements like “All programming languages have their place.”
But of course, some tools are simply obsoleted by other tools. While Rust won’t serve your needs if what you really need is garbage collection, there are very few scenarios where C++ still beats Rust for new development. Sure, C++ has improved over time, but Rust doesn’t have a legacy to weigh it down, and so can actually do things right the first time.
Some people disagree with this in a way I respect, because of support for optimizing compilers, or the vagueness and immaturity of the semantics of unsafe Rust, or some other concrete reason where C++ has something to offer as a tool. Others simply live in worlds where too much code is in C++, and it would be impossible to migrate anytime soon, and that also makes sense to me. But I simply cannot take seriously an assertion that in some axiomatic way, reminiscent of the intrinsic value of all human beings, every programming language has its value.
Why should this be true? It’s not like which programming language someone uses is an intrinsic quality. I’ve changed from a C++ programmer to a Rust programmer, and so can you. Perhaps some of the people saying this are hobbyist programmers, asserting the right of people to enjoy C++ personally, and to program it as nerds. And that’s fair! But that’s also not what I’m talking about. I’m talking about what the best programming language is to use for projects that people will use in anger, where it matters whether a language is likely to lead to security vulnerabilities when used. If what programming language you use for such projects is a key part of your identity, then that’s not an OK way to structure your identity.
If it were true that all languages had their place and their value, does that mean that there should be shops writing in the obsolete versions of C++, like the original C with Classes? Does that mean that there should be shops writing code in INTERCAL? Does that mean that there’s some situations in which it’s best to do greenfield development in COBOL?
One example of this trope is the famous essay "‘Considered Harmful’ Essays Considered Harmful", which has of course been cited to criticize my own “Considered Harmful” post (for more on the “Considered Harmful” trope, see the Wikipedia article). Ironically but unsurprisingly, “‘Considered Harmful’ Essays Considered Harmful” is dogmatic in exactly the way it criticizes, in spite of giving itself a (silly and ill-defended) out. In spite of recommending that “considered harmful” essays be replaced by “benefits and weaknesses” lists, or even “perceived benefits and weaknesses” lists, it does not follow its own advice. It does not list benefits of the “Considered Harmful” essays it considers harmful.
So I will fill in this deficit. “Considered Harmful” essays are good when a feature of a tool does indeed cause harm, and a better option is available – as is often actually the case. The title is a cliché, which is a good thing in this case: it signals to the reader, in a light-hearted way, what the thesis of the document is – as opposed to “benefits and weaknesses” lists which tend to be biased in any case and can amount to passive-aggressiveness. Weaknesses in one’s argument or benefits in one’s opponents argument can and should be acknowledged and addressed, but that doesn’t mean you have to pretend not to have a position. Just because something has some benefit doesn’t mean that it can’t, overall, be fairly considered harmful.
Indeed, my own post did do some “benefits and weaknesses,” in spite of being titled as a “Considered Harmful” essay. It did spend some time explaining why C++ made the decisions they did, and what the benefits of C++’s decisions were, even in the context of a post about why these decisions were considered harmful. C++ had to implement non-destructive moves for backwards-compatibility. They had boxed themselves into them, harmful as they are. That doesn’t make them any less harmful, but it does make them understandable.
So I disagree with the people who have used that post to criticize me, and ask them why they don’t also turn the arguments of that post against itself. Perhaps I could write:
‘“Considered Harmful” Essays Considered Harmful’ Considered Harmful
The only problem with this would be how to punctuate it. That and, I’m sure it would widely be considered… quite silly.
Conclusion: Restatement and Summary#
Programming languages are tools. They are important tools, so it’s good to make sure they are of high quality, and do the things we demand of them, because they are often asked to do critical tasks for society. They are also not to be conflated with the people using the tools, who can retrain on new tools if they’re worth their salt.
Tools should not be idolized, and tools cannot be perfect. It is impossible to make a tool that can serve any purpose equally well – programming language design, in particular, will always have trade-offs. However, it is possible to make a tool that loses to another tool in all categories, and that is what C++ will soon be in comparison to Rust, if it is not already there.
And C++ programmers have their place in the new Rust world – it’s very easy to learn Rust from a C++ background. And C++ history has its place there too – Rust builds on C++, and it wouldn’t have been possible without the contributions of those who worked on making C++ what it is. Everything that is community about C++, everything that is people, everything that has moral value, can be migrated to Rust.
But that doesn’t mean that C++, the tool, has a place in production programming beyond legacy (i.e. pre-existing) projects. Again, there still may be a few other valid reasons to favor C++ over Rust (though they’re getting fewer and weaker with time), but a bald assertion that “every language has its place” is not one of them.
NewsletterFind out via e-mail when I make new posts!