> But the major players do seem to be happy to replace their C++ code with Rust.
Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.
The set-up and your reply feel like a Rust sketch.
Not touching a codebase only applies to legacy software which is feature complete.
Any actively developed software will benefit from incremental improvements.
Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.
Note that an incremental language improvement doesn't mean a small code change. For example, C++'s iterator with two related but technically independent pointers is a PITA for alias analysis, which is a problem not only for Circle/Safe C++ but for WG21 Profiles too (https://www.circle-lang.org/draft-profiles.html). An incremental language change would be to adopt a Rust-like iterator. That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.
Bjarne still sees C++'s safety problem as lack of adoption of Modern C++. WG21 is catering to C++ users who will not make such changes.
WG21 has firmly rejected everything resembling Rust's borrow checking (a solution that now has a decade of proven track record, and has been demonstrated to be possible in C++ via Circle/Safe C++). Addition of "pervasive annotations" is so unacceptable to WG21's view of C++ that they're still insisting on Profiles.
“Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched.”
That was most of your original comment and it remains wrong.
Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.
“An incremental language change would be to adopt a Rust-like iterator.”
One of many possibilities.
“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.”
Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.
Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.