And so, as they say, we should all be using Rust. But allow me to explain why I don't yet.
Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc.
This interacts with the finite amount of time I have to learn a new language, making it take longer before I feel proficient enough in it to start using it for real work. Sufficiently long that the day that I do is still in the future.
I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.
> I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.
What you say would make sense if Rust were based on C++. I've never heard anyone say that.
I was under the impression that Rust is a derivative of ML, and (to me, at least) it looks very much like StandardML or OCaml with a borrow checker.
(I don't know C++, so I can't personally comment on how similar or different it is from Rust)
"It's a C-like OCaml" was how Rust was originally described to me, when I first heard of it.
I am not really even criticizing Rust. Let it be what it is. Python isn't C++ either. All I'm saying is that if the goal is to increase the number of people using memory safe languages, adding a borrow checker to C++ would serve that goal.
(Also, I would really like to have a language with both a borrower checker and actual C++ templates.)
(And yes, I fully support making C++ safer too; the GSL is as close as we're going to get, probably.)
How about a language that embraces Turing-complete template metaprogramming as a thing to design in on purpose rather than something discovered after the fact to be more useful than anticipated. Have the utility without the ugly.
(And the reason it's taking such a while is that we are actually doing that...)
In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library . You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well .
 shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
Which they are extending to also support their C++ lifetime checker.
You could potentially even continue to support the existing ones but regard them as unsafe and have the compiler warn if they're used.