3 ms·

As someone whose career has been mostly in Java/Python/Ruby but is also comfortable with C, learning Rust has been like a step function, where each time I get s

As someone whose career has been mostly in Java/Python/Ruby but is also comfortable with C, learning Rust has been like a step function, where each time I get stuck I correct some discrete misperception and then have an easier time. I wish I had written these down, but here is one that helped me a lot and is also a little funny: When Rust folks talk about "move", it is not just jargon about ownership. They actually mean move to a new place in RAM. If you could do a printf("%p", foo) before and after, it would be different. So obviously if there are other pointers to that object, they aren't going to be valid anymore. Figuring this out really helped me reason about what was allowed and what wasn't. Maybe it will help out someone else too. "Oh, you mean move!" :-)

khuey 9y ago
> When Rust folks talk about "move", it is not just jargon about ownership. They actually mean move to a new place in RAM. If you could do a printf("%p", foo) before and after, it would be different. That's not really true though. In an optimized build rustc will elide memcpys whenever possible, which it often is. "Move" in Rust really is about ownership.
- pjungwir 9y ago
  That is true, but personally I think about that as coming "after" all the ownership stuff checks out, and as an implementation detail that I can usually ignore. I do keep it in the back of my mind though. Btw I have a saying: when you teach, at first you have to lie a little. You paint the broad strokes, then you refine, then refine again, etc. So it's a question of what is a helpful mental model. Knowing the optimization behavior is helpful for some things, but for figuring out valid memory behavior it's useful to pretend you don't know about that.
pjungwir 9y ago
Another breakthrough I recall was understanding that there are three alternatives: move, copy, borrow. I don't know about the docs nowadays, but when I was starting it seemed like explanations would always pick two of these and describe the differences in a binary way. That made things hard to retain, because it was like the spatial layout in my head was always shifting. Establishing for myself that there were three was very helpful early on.

khuey 9y ago

> When Rust folks talk about "move", it is not just jargon about ownership. They actually mean move to a new place in RAM. If you could do a printf("%p", foo) before and after, it would be different. That's not really true though. In an optimized build rustc will elide memcpys whenever possible, which it often is. "Move" in Rust really is about ownership.

pjungwir 9y ago
That is true, but personally I think about that as coming "after" all the ownership stuff checks out, and as an implementation detail that I can usually ignore. I do keep it in the back of my mind though. Btw I have a saying: when you teach, at first you have to lie a little. You paint the broad strokes, then you refine, then refine again, etc. So it's a question of what is a helpful mental model. Knowing the optimization behavior is helpful for some things, but for figuring out valid memory behavior it's useful to pretend you don't know about that.

pjungwir 9y ago

Another breakthrough I recall was understanding that there are three alternatives: move, copy, borrow. I don't know about the docs nowadays, but when I was starting it seemed like explanations would always pick two of these and describe the differences in a binary way. That made things hard to retain, because it was like the spatial layout in my head was always shifting. Establishing for myself that there were three was very helpful early on.