I'm not sure that's true -- I think most developers use whatever is fashionable in their circle at the time, and then the project gets locked into that tech. In some circles, they're old enough to stabilize: kernel developers are attuned to C, and will rarely consider anything else regardless of option-availability, because their entire ecosystem (and by virtue, culture) revolves around C. C of course was picked in the first place because of the fashion at the time kernel development got into gear.

That is, kernel devs got into bed with C before it was a "clear winner", and now they're stuck with it.

Ecosystems that are still developing, layered on top of these older more stabilized systems, have the freedom of choice, and they certainly make use of that freedom.

And of course, by nature of a non-stabilized ecosystem, most choices made are done before a clear winner exists -- because no clear winner exists just yet. But the choice will stick, unless it was dramatically harmful to the project.

The older the ecosystem, the less viable it is to select anything other than the clear winner, because the ecosystem is coupled to that clear winner, and the ecosystem is the fashion.

Which is why I write Elm code at home, but Javascript at work. I'm told the latter is the right tool because the company might have to hire someone to maintain it in ten years, and there just cannot be any deviation because any other language would make that ethereal future hire too expensive.

That excuse reflects very poorly on the planned future of the company I work for, but I don't think my bosses recognize that.

It's apparently less important that our applications are crash-resistant by design of the platform rather than the application itself. I'll admit I'm a bit of a diva with regards to available tools but it's getting really tiresome.