Language choices does make a decent difference to time spent, bugs, extensibility. Id guess a 20-100% tax for choosing the wrong language. However most of the time the best language is the one the team knows well. Caveat to that is if the threading model or performance doesnt suit. Or company platform engineering reasons (e.g. availability of platform libraries).

> Caveat to that is if the threading model or performance doesnt suit.

So, this goes for ~70% of all projects ever and ~95% PLs ever?

I would have been a staff Golang engineer, if not a VP of Eng even, somewhere at this point if I didn't fall in love with Erlang's concurrency & parallelism implementation.

I am kind of still offended by the entire IT area that we have multicore CPUs for what, 20 years now, and we still don't make true physical parallelism a first-class citizen in all of our mainstream PLs. Looking at you, Python, and looking at you, Golang, with your ability to crash the program for sending to a closed channel, and looking at you Rust for making async needlessly complex.

(RE: Python, yeah yeah, "GIL is going away next release" and stuff. With that tempo they'll catch up with Golang by 2050.)

Frameworks are a major contributor to these dynamics, which is a little unfair to blame on the language, but I've seen orders of magnitude difference.

I had one time it was faster for the three of us to rewrite a web app in Rails than to make the Play framework accomplish what we wanted it to accomplish, even though none of the three of us had ever worked in Ruby before. Rewriting four months of work took two weeks because Rails neatly supported what we were doing and so much could be generated. We ended up with better test coverage too.