Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?
I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to make the choice, you are less likely to make yourself change (and more likely to make the junior people change, when there's a trade-off). Power corrupts, even on that small scale.
There's also a good argument for being stubborn and jaded: You have 30 years perfecting the skills, tools, efficiencies, etc. of C++. For the new project, even if C++ isn't as good a fit as Rust, are you going to be more efficient using Rust? How about in a year? Two years? ... It might not be worth learning Rust at all; ROI might be higher continuing to invest in additional elite C++ skills. Certainly that has more appeal to someone who knows C++ intimately - continue to refine this beautiful machine, or bang your head against the wall?
For someone without that investment, Rust might have higher ROI; that's fine, let them learn it. We still need C++ developers. Morbid but true, to a degree: 'Progress happens one funeral at a time.'
I believe the opposite. There's some kind of weird mentality in beginner/wannabe programmers (and HR, but that's unrelated) that when you pick language X then you're an X programmer for life.
Experienced people know that if you need a new language or library, you pick up a new language or library. Once you've learned a few, most of them aren't going to be very different and programming is programming. Of course it will look like work and maybe "experienced" people will be more work averse and less enthusiastic than "inexperienced" (meaning younger) people.
The "You can write Java in any language" mentality afflicts some languages worse than others, but if your programming is exclusively in a single language you will be tainted by that regardless of the language. C++ is perhaps worst for this because its proponents, and indeed its standards committee have their own terminology for everything. So there aren't "methods" but instead "non-static member functions" for example. This has the "Call a rabbit a smeerp" problem, where you can't tell whether you actually don't know a feature or if you just know the exact same feature by a different name.
I guess what I'm saying is that writing any language in an idiomatic way takes a bit more than just "programming is programming" plus a word-for-word translation guide, and some people might be weary of learning new idioms.
That heavily depends, if you tap into a green field project, yes. Or free reign over a complete rewrite of existing projects. But these things are more the exception than the regular case.
Even on green field project, ecosystem and available talents per framework will be a consideration most of the time.
There are also other things like being parent and wanting to take care of them that can come into consideration later in life. So more like more responsibilities constraints perspectives and choices than power corrupts in purely egoistic fashion.
Not most, but the pool of software devs has been doubling every five years, and Rust matches C# on "Learning to Code" voters at Stack Overflow's last survey, which is crazy considering how many people learn C# just to use Unity. I think you underestimate how many developers are Rust blank slates.
Anecdotically, I've recently come across comments from people who've taught themselves Rust but not C or C++.
Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.
It is easy to forget that the state-of-the-art implementations of a lot of systems software is not open source. They don’t struggle to attract contributors because of language choices, being on the bleeding edge of computer science is selling point enough.
I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).
I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.
Multithreading had not been planned or architected for, it took 30 min, included the compiler informing me I couldn't share a hashmap with those threads unsynchronised, and informing me on how to fix it.
These days even mobile phones have multicore CPUs, so it's getting hard to find excuses for single-threaded programs.
Zig would have been a nice proposition in the 20th century, alongside languages like Modula-2 and Object Pascal.
> ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free
which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".