I find it hilarious to watch programming language partisans astroturfing. Sometimes I even play along.
But as far as I’m concerned, things are pretty clear cut: You pick the right tool for the job, and even if you have favorites, you learn their weak spots as well as their strong suits.
By and large, and given that the most important factor in program design tends to be the way your data is structured and not the language you’re manipulating it in (a fact that pretty much everyone tends to forget at one time or another), I tend to pick a language based on the environment I’m working in.
In my experience, there are usually three types of environments:
- Environments you control
- Environments you have to put up with
- Environments you need to keep abreast of (or are exploring)
For me, what to pick in the first kind of environment is pretty clear cut: I can choose what to use, so I’ll use what I’m most productive in given problem constraints (which, these days, is mostly about performance and networking).
I do most of my stuff in Python because it saves me a lot of time when tackling weird inputs, alien web services and accessing all kinds of data stores, drop down to Go when I need more speed (or, in case of resource-constrained environments like ARM boxes, when I can’t be bothered to do C/C++), and use Clojure whenever I can for the sheer power of it1 and as a neater, cleaner way to use Java libraries.
Go is a fairly new addition to my arsenal, and I kept tabs on it for a year before finding it “good enough” – mostly as far as the ecosystem was concerned.
And in between those three ecosystems, I’m guaranteed to find whatever third-party stuff I need to stop me from reinveinting the wheel – all of them are, if not mature, then at least guided by mature reasoning and tend to have pretty straightforward “best choices” for common tasks – even though the Go stuff is still a bit thin on the ground when compared to the variety in Python and the utterly amazing Java/Clojure universe, it’s shaping up quite nicely for its intended purpose (that is, high performance systems programming).
You’re either constrained by the runtimes available or the tools you have to use, and it thus makes little sense to, say, target Android in anything else but Java – you can use a number of other languages, but you’ll usually be talking to core APIs, and if you’re pressed for time (and have nothing fundamentally against Java other than its ceremony) you’re much better off biting the bullet and diving in.
The third kind of environment is the hardest to define – for me, it’s both a matter of keeping my skills sharp (Mono and C#), keeping tabs on things like Scala (which I’m not particularly keen on but can’t ignore), or dipping into OCaml/F# (which I’m quite keen on but have yet to dive into).
But the main point is that all of this is temporary (one might even say ephemeral). It wasn’t like this five years ago (not even one year ago, really), and I have no idea what it will be like six months from now (or even if I’ll still bother with programming languages). It’s your mind that counts, and what you do with it.
I’ve also been employing a rather potent cocktail of Hy, Go-like coroutines and PyPy, which has the side benefits of starting up faster than Clojure and allowing me to employ all my favorite Python packages for data munging, but that’s another story altogether. ↩︎
I tried. I really did (and still do on occasion), but to this day I keep finding that the mental overhead involved in trying to twist regular program flow into spectacularly brittle (and leaky) tangles does not pay off – either when you manage to get it working or six months down the line when you try to grok it all again. ↩︎