Does the choice of programming language matter?

For years, many programmers would answer “no”. There was an “OOP consensus” across languages as different as C++ and Python. Choice of programming language was just a matter of which syntax to use to express the same OOP patterns, or what libraries were needed for the application. Language features like type checking or closures were seen as incidental, mere curiosities or distractions.

To the extent there was a spectrum of opinions, it was between OOP denizens and those that didn’t really think software architecture mattered at all — an feeble attempt of corporatization against true programmers and their free-spirited ways. The office park versus the squatters. That’s how we got the wave of so-called “scripting languages”.

But OOP was the least of their concerns. They shrugged along with some sort of class system, and save their criticism for (static) types and compilation (an implementation strategy, not language property).

Now, times are changing. When in the last 30 years have we seen so many concurrent pivots in major languages?

Perhaps it began with lambdas. Once, they were seen as curiosities from the functional world, a special case of an OOP class overriding a single method (which is exactly how you had to write them in C++ in Java). Now, Java has lambdas. Even JavaScript thought its function() syntax was too heavy, replacing it with a lighter-weight =>. Hold up, even Excel has lambdas. Functional programming has intruded against the mainstream consensus.

When this intrusion broke through, the old equilibrium cracked. Both the OOP consensus and scripting language counterculture started to crumble. Now, Javascript, Python, and Ruby are getting type checking. Java is getting a whole mish-mash of “functional” features. C++ is de-emphasizing inheritance and doubling down instead on templates. Even Go is getting generics.

So here we’ve reached a funny point. Before we had a bunch of languages which roughly did the same thing. Now we have the same bunch of languages all adopting the same features they never dreamed of having before. Within that cohort there is still little reason to adopt one or another, but over time there are clear reasons to choose the newer versions over the older versions. You might not care about Java vs Go, but you sure as hell want the version with generics over the versions that don’t.

So among 20+ year old languages, the choice of languages absolutely matters for programmers with time machines (or contemplating Debian stable), but what about for the rest of us?

Well, there are newer languages now mainstream (enough) too. And here we find the front of the pack, the language bringing functional features into the mainstream more completely and thoroughly than others (because being born with them helps): Rust.

There are other languages zooming out in front of the pack, leading Rust just as Rust leads the others. Being way out ahead is exciting. But it can be lonely. It might be cold. And you might run out of steam. Being at the front of the pack, the furthest along of the mainstream, is nice. You still see where we’re going better. You go there early. But you’re not alone; you’re shoulder to shoulder with others doing the same.

If that sounds nice, learn Rust. Don’t learn it as a mish-mash of exotic cool features. And don’t let it lull you into thinking you must do some sort of whiz-bang systems programming that almost no one does.

Learn Rust, idiomatic Rust, yes, for solving all the mundane problems you face in your programming life, but also to get a head start on what will be the next era of accepted programming practice. Learn type classes (aka traits) in their full power (and not just the object-safe ones), and learn how Rust’s move semantics can be used to simulate type-state.

These features might seem niche now, but remember, so once did lambdas.