I think you will appreciate that moving objects actually invalidates the original bindings and the compiler checks for this quite effectively.
Though there is some learning curve..
Though there is some learning curve..
Then it also has a borrow checker so if you refer to the content of an other object the langage ensures the (non-owning) pointer does not outlive the pointee, at compile-time. Though this concept is lexical so it’s quite restrictive.
And then it encodes some forms of thread-safety in the langage directly.
It also removes things like nullable pointers.
Essentially all the stuff that makes std::move questionable "just works" in Rust. It doesn't even exist, values are moved by default and clones must be explicit (equivalent of a copy constructor for non-trivially copyable types).
The other giant advantage is that use-after-free doesn't exist in safe Rust, since you can't have a reference to a value outlive the value.
* It is also a compile error for a closure that captures a value by reference to outlive the value.
I can't tell if one if us is confused here or if this is just confusing wording, but the check I referred to is not bug-prone. The pattern of using something after it's been moved from is bug-prone (even though it'd work fine for things like integers, in either language), and it's checking for that bug-prone pattern, hence the name.