The "more to it" is that the use-after-move checks aren't bugprone in Rust, you cannot use a value after it has been moved in safe code (additionally, when you call a function, values are moved and not copied, and when you capture a value in a closure, it is either by unique mutable reference, immutable reference, or moved and therefore safe*).
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.
> the use-after-move checks aren't bugprone in Rust
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.
In Rust it’s not bug–prone. The compiler knows which types are moved and which are copied, and if you write code that uses something after it was moved you get a compile–time error.
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.