> I've seen it. There are definitely incorrect language choices for certain projects.
I guess we can all agree that writing your web application using a fortran framework to generate JS code is a bad idea.
But if you pick tfa's second example, picking Go vs. Rust for a new project, the language choice is secondary. Both languages were likely fine unless the project as a specific library requirement.
The main criteria to make the choice was likely whether the team had developers with some experience in that language, and whether using that language would make them feel dead inside in the morning when they check in ; and I'm pretty sure developers can be found that make either choice a great choice.
The point tfa's making, that picking a language defines culture, the hiring pipeline etc. is fitting neither the first example (team already there, and a rewrite is almost always a bad choice) nor the second example (team also already there, and the culture with them. Pipeline therefore irrelevant).
In my first post, the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. I choose Python just because anyone who would argue that is a good choice is clearly not someone who is in a position to see reason. But I think Go is a serious mistake... it's just one that lets you get to market, unlike Python which never would. But it's still going to end up holding back the company that makes that decision in the end.
> the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database.
You mean they're writing their own database? Why? That's a huge job and available databases are pretty good. There are multiple open-source choices, all of which work.
If they think they're going to compete with Oracle, they need to read the history of Oracle.
There are many workloads for which all available database engines are poor. If you have one of those workloads and the esoteric technical expertise, it is entirely plausible to improve performance, scale, etc metrics by 10-100x versus whatever is currently available in the market. 10-100x is qualitative if that is central to your business.
Of course, almost no one should attempt this. The number of people with the technical expertise to pull it off successfully is much, much smaller than the number of companies with workloads that would benefit from this.
It doesn't have to be an exotic workload. Sometimes the market is just full of weak implementations e.g. graph databases.
There are at least a dozen new databases in the market making decent money that were started this decade.
They're just not competing with Oracle.
A large part of success is picking a goal that is obtainable.