C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.
Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the programmer to reuse the object itself). It gains some ability to optimize by forbidding unwinding during a move.
> I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust.
That's not the goal. The goal is to provide a tool for new projects like Servo, or incremental partial rewrites like Firefox, or new infrastructure like ripgrep.
This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ?
> Rust avoids the null state problem by statically omitting the constructor call
You seems to be conflating move semantics and move optimization...
Static omission of destructors in Rust is more than just an optimisation: locals (and other values) never have their destructors run once they've been moved-from, and thus no values need null states, and moving a value doesn't have to run arbitrary code (it can be, and is, just a memcpy).
Oops, too late to edit but that was meant to say "destructor."
So - we can implement threads without data races if we implement threads without data races? The reason people cite memory safety as a feature of Rust over C++ is because you get it for free, without having to do any additional work to achieve it.
Nothing is free, language design is an exercise in compromise. OP might need to calm down a bit with the aggressive language, but underneath all that there is real message from people using (trying to ?) use modern C++ : The added safety you mentioned can 1) be really well approximated using modern C++ technics, 2) addressed by really well engrained coding standard and practice learned and known for a long time and doesn't apply for the in the unsafe part of rust that some of the libraries have to use. But i doesnt come at the cost of reduce expressiveness in the safe part of language, slower compiler time and high learning curve.
But it can become a hot place for higher-level people to do lower-level things and rapidly learn a lot, as it has for me and some other Rubyists.
Modern C++ has made great strides in the direction of making writing good code a lot simpler. I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust. It's just not viable.