> We will understand that those people are the ONLY ones that stepped up to the task over 50 years to write this kind of software
Not to take away from what they've shipped, but it bears repeating that they are also, generally, profligate writers of severe security holes. Some of the most expert programmers in the world have created mighty CVEs.
There's a school of thought that it's a poor craftsman who blames his tools, and your post walks close to that line, but when the tool is full of footguns even the experts can't avoid that cause tremendous damage to bystanders, then perhaps these people who know how to organize themselves in loose groups of more than just a few developers need to prioritize helping us all move to better tools.
Other segments of the programming population embrace a wild west culture of change, for good or bad. If the JS world can insist on a new frontend stack every few years, why can't managers and lead developers put their foot down and steadily back C/C++ into the corner where it belongs, where literally no other tool will do, and where it's doing the absolute minimum possible?
Since they're so good at shipping, ship us better tools! It may not seem a fair criticism -- it doesn't sound fair to me when I say it.
But I'll give you the answer to my question: They don't want to move away from C/C++, because they don't see a problem. The C/C++ devs I've chatted with on this topic have mostly been convinced they know how to write secure code, that they are capable of taming the distinctive complexity that spirals out of an expanding C++ codebase. Some of them might even be right! They wear their capabilities with pride. To admit that their hard-earned skills were invested in a tool that bears replacing is not something they can consider.
To change, first you have to admit you have a problem. And at least among the C/C++ devs I've talked to about it, few have professed a problem. Combined with the first mover advantage, I fear we'll be having this same debate 50 years from now.