> 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.

Sure, people with ZERO enterprise experience might say - hey, let's write our <main software> in PHP - I had a lot of fun 15 years ago with that, and I'm sure we can make it work.. That's the "3 toothpicks" in your example.

But is anyone REASONABLY competent going to do that? They might pick C/C++, Go, Rust, Java, etc. Those aren't a choice between "bulldozers and toothpicks" - they are more akin to choosing between Caterpillar, Volvo or Hitachi as the vendor of choice for construction equipment. They may have some gaps in their specific list of equipment, they may charge too much for one specific tool, your workers may have experience with one, not the other, etc..

Your example should be the textbook definition of a strawman argument..

> Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project

Just to be clear, I wasn't trying to claim this; tooling certainly matters, at the very least, for the happiness and welfare of an engineering team! But, the article tries to claim things like "choosing a programming language is the single most expensive economic decision your company will make" and outside of a few extreme edge cases, I just can't agree with that particular thesis. Even the examples of bad decision-making you pose in your sibling comments, like writing a database in Go or "almost failing" by using sketchy niche datastores, are actually examples of this exact thing: these projects made huge engineering mistakes only to achieve some level of success as a business. Would they have been more successful if they made better engineering decisions? Possibly, but again, language and framework just was not the most important decision or factor driving an outcome.

I'm not saying that means we shouldn't care about making good engineering choices; there are easy ways to do things and hard ways to do things, and certainly I'm going to advocate for and work with people and at companies that favor the easy ways to do things. But when it comes to overall outcomes, I'll stand by having seen far more projects sacrificed to analysis paralysis, rewrites, rewrite-related hand wringing, and language/tooling hubris than sabotaged by poor language and framework choices.

> But programmers seem to feel that they are above this stuff.

No, programmers are quite below this stuff. Budgets for medical research, treatments, trials are way more than IT budgets. And for typical IT project the underlying point is even if requirements were wrong, changed halfway , software is malleable enough, to be changed, refactored. And all while it can remain in use even during change cycle.

The parent article's point, though, is that choice of programming language is often NOT driven by justified choices, but is a foregone conclusion because it is part of the identity ("I am/want to be a XY developer.") of someone influential (e.g. tech lead, CTO, VP Eng).

One argument I would like to add to this original debate is that I have observed two types of developers: one type tries to stick to one programming language for everything (e.g. Java) and tries to write everythin in that language. They are specialist and they may accrue deep knowledge of the language versions, APIs and IDE(s). Another type of developer, in contrast, maintains active knowledge of a dozen programming languages (C/C++, Java/Kotlin, Python, bash, Rust, Go, PHP, JavaScript, ...), and is capable of delivering projects in each. They'd pick a language suitable for the task and stick with it for a project. They won't know any single language as intimately as the first type, but they benefit by virtue of their choice of language being more appropriate to the given project.

If you are starting from scratch fortran is a bad choice. However if you have a fortran project that keeps getting more features you may become an amazon clone along the way