Rust for Professionals

From the standpoint of being productive in Rust, this is what you need to know:

* An object has a lifetime. This generally lasts until overwritten or destroyed at end of scope.

* You can loan out references to this object. You can either have a single &mut, xor an unlimited number of & references, but not both.

* References cannot outlast the lifetime of the object they point to.

* If you have a &mut reference to an object, you can give out another &mut reference to the same object. But you can't use the first reference for the duration of the second.

* Lifetimes can be named, and you can express criteria of the form "this lifetime must at least/most this long."

* Bonus: if you have &mut x, you can give out &mut x.a and &mut x.b at the same time. But you can't give out &mut x while such a subreference is live.

And... that's really all you need. Yeah, there's a lot more rules, and there's definitely fun edge cases around things like temporary objects' lifetimes. But there's no need to know all of that stuff. If you get things wrong, the compiler will come back and slap you in the face and give you an error message--that's the selling point of Rust, getting lifetimes wrong is an error, not silent nonsense--and your task at that point is to figure out if you're really breaking a cardinal rule (two or more mutable references to the same memory location, or references not lasting long enough), or if you didn't enforce sufficiently strict requirements for the bounds of the lifetimes. And the rust compiler is pretty good at telling you what you have to do to get necessary lifetime bounds (sometimes too good--it can suggest fixes to lifetime bounds even when such bounds are unachievable).

I'd compare this to things like name lookup and overload resolution in C++, which are actually horrendously confusing algorithms that almost nobody understands in their entirety. Yet plenty of people can be productive in C++ because the general principles are well-understood, and if you're at the point where you need to descend into the morass of exceptions and exceptions-to-exceptions, you're probably writing confusing code to begin with.

I found the copy/move situation in Rust to be far less intuitive than in C++. In C++, move semantics are obvious because they rely on std::move and the && operator, whereas in Rust, similar behavior seemed to depend on the object type. Even more confusingly, Rust has its own move operator as well, despite destructive move being the default behavior for assignment.

I found it frustrating enough that I put the language down and just went back to using C++.

Also very important realization is that things that are moved around (assigned to variable, moved into or returned from a function, kept as a part of the tuple or a field of a struct) must have fixed and known size. And the variable itself is not a handle. It's a fixed sized area in the memory that you named and moved something into it.

This makes completely logical why some things must be Box'ed and borrowed. Why you cannot treat Trait or even impl Trait like any other type. Why sometimes it's ok to have impl Trait as your return type while in other cases it's impossible and you must Box it.

Third important realization is that things borrowed out of containers might be moved 'behind the scenes' by the container while you hold the borrow, so you are not allowed to mutate container while you are holding borrows to any of its contents. So it's ok, to instead hold indexes or copies or clones of keys if you need.

Another observation is that any struct that contains a borrow is a borrow itself. Despite using completely different syntax for how it's declared, created, it behaves exactly like a borrow and is just as restrictive.

Last thing are lifetimes, which don't have consistent (let alone intuitive) syntax of what should outlive what so are kinda hard to wrap your head around so you should probably start with deep understanding what should outlive what in your code and then look up how to express it in Rust syntax.

Rust is syntactically very similar to other languages, but semantically is fundamentally different beast. And while familar syntax is very good for adoption I'd also prefer tutorials that while showing the syntax explain why it means something completely different than what you think.

> In C++, move semantics are obvious because ...

In Rust it's also obvious because every = is a move. Confusion comes from tutorials pretending for too long that it's not.

> whereas in Rust, similar behavior seemed to depend on the object type.

It's best to think of that as an exception to the rule created specifically for numbers and other similar small, cheaply copied things.

If you need to move `a` but `a` has a trait Copy then you copy instead.

> Rust has its own move operator as well, despite destructive move being the default behavior for assignment.

I don't think that's true? Rust has a `move` keyword but it's a part of closure definition that makes it take all the variables from its environment by move, even if it doesn't need it. Unless you are talking about something else...

You add '.clone()' or '&', the code compiles, you move on.