Good post. I think this is the mature and somewhat inevitable lens through which to assess which programming language you're using. I have been using primarily

Good post. I think this is the mature and somewhat inevitable lens through which to assess which programming language you're using. I have been using primarily Python for the last ~4 years or so. It's probably the most boring language I have ever used (it probably doesn't help that I've used Scala, Haskell, Rust, etc). Obviously, some languages are better than others for specific use-cases and one should think through the strengths and weaknesses of each before beginning a new project (assuming you expect the project to have some longevity). Similarly, it definitely is possible to make the wrong choice about which language to use. But even as a PL "enthusiast", I've learned over ~15 years of leading successful projects and teams, that evaluating languages is always team/org/business-dependent and the considerations that factor into those contexts are distinctly different from the kind of considerations that I, as a PL enthusiast (and I suspect many others in the HN crowd) would prioritize. You have to consider things like: 1. What stage in the business in, i.e. early stage where you may simply want to get something, anything working and it's viable to do so in whatever language will get you there fastest (warts and all, tech debt be damned, etc) vs the critical juncture where you're beyond finding product-market fit and you now have a business that is working and you need to increasingly focus on reliability, scalability, etc? 2. What does the pool of engineering labor in the market you have access to look like? For example, it may be the case that you'll have difficulty, for one reason or another, finding developers who work with language X, but could easily find many who can work with Y (of course, good devs should theoretically be able to ramp on any language, but whether you'd want them to do depends on how crucial using that particular language is to your venture, whether you can afford the ramp-up time, etc. 3. Also somewhat related to the quality of engineers you have access to, the community/packages/ecosystem surrounding the language may matter a lot to such a degree that even if some other language were a better fit from a purely technical perspective, it may leave you to have to fend for yourself in ways that your team simply isn't up for. .. and many more considerations. Beyond all of this, I resonate with the author's orientation of wanting the language to just get out of the way. Sometimes you're looking to geek out on a stimulating and interesting language. Other times, that's the last thing you're thinking about. Bonus points if the language you find most compelling is also the one that, for reasons like the ones mentioned above, is the one that makes the most sense for you and your team. All in all, the point is that assessing a language in isolation, without any regard for what you're actually trying to accomplish, what your team looks like, etc. doesn't make much sense. Side note: I do wish more Substack authors would allow comments even from non-paid subscribers. I could understand restricting it if you already have an established paid subscriber base and a chatty comments section. But if comments are non-existent, it seems to me like the author is potentially losing out on valuable feedback/commentary by restricting commenting to paid subscribers.