That makes sense.
I do think that the really big problem right now is incorrect assumptions about Rust based on what little people have heard about it. For instance, in a discussion in which I was criticizing C++14’s failure to permit
std::function to contain a
std::unqiue_ptr (or any other non-copyable object), someone was defending C++ by stating that my original design had a “logical” error, and that in fact “given the pedal-to-the-metal nature of C++, this specific issue is unavoidable”. (This idea among the C++ community that all of its flaws are necessary flaws for a “power language” is frighteningly prevalent.) I explained that this issue would be avoidable if
std::function supported move-semantics, and that this gave me the feeling that C++'s move-semantics are a “tacked-on” part of the language rather than a core part of the design as in Rust. The person responded by saying that his “theory” was that Rust handles this situation is “garbage-collected pointers”. I of course explained that Rust does not have garbage collection, but I think the discussion highlights a fairly common misunderstanding–that memory-safe languages necessarily use garbage collection. And in the C++ community, garbage collection seems to be anathema (despite the fact that Bjarne Stroustrup has stated that he has no doubt C++ will some day incorporate garbage collection–a prediction I think is actually pretty unlikely).