> As said earlier, C++ developers have an advantage on understanding Rust because they have a mental model of what the memory looks like, pointers and so on<p>The immeasurable success of Rust certainly lies in its clear communication and forcing developers to learn about the basics of hardware.<p>I can't help but to feel validated in thinking that every developer worth its salt should know about these basics anyway. But I have to admit that not everybody comes with a CS background.
Personally, I'd recommend learning C to learn about the basics of memory management in higher level languages in general. It is simpler than Rust and is very transparent, making it easier to grok the concepts before moving on to something like the borrow checker, further more, it will actually make the <i>motivations</i> for the borrow checker and what it does to help clear. Same goes for other memory management solutions, gc, reference counting, etc. So much of what we do is <i>still</i> bound to a deeply entrenched model that C established.<p>Ultimately we are all still just writing nicer versions of C. The fundamental model of pretty much all high level languages remains the same. You can still explain and think about the vast majority of memory related goings-on in a program as using the basic abstraction of the pointer and contiguous arrays of bytes. Even languages that have different paradigms, be they functional, logical, or object oriented can be described in terms of pointers--one easy way to understand pretty much every other programming language paradigm is basically just to ask "how would I implement this using pointers?". It's a shared history and approach to computing we have yet to move on from.
Today I had a moment with TypeScript where I got an error because a class property wasn’t definitely initialized in the constructor.<p>I thought, “I wish there was a way to prove to the compiler that it will be there when I access it, rather than having to tell it to trust me.”<p>And that’s when lifetimes in Rust really clicked for me. I know it’s not exactly the same thing but the <i>value</i> of describing the valid lifetime of a thing at compile time began making a lot more sense.
> As a rule of thumb, if you don’t want the function to consume the data (to free it), don’t ask for ownership.<p>As a Rust beginner, that's a handy thing to remember! Thinking of variable passing in terms of least privilege seems much better than just trying to use the simplest syntax (changing ownership by passing the variable rather than a pointer to it) all the time.
> Ideally, you don’t want to make a self-referential struct in Rust. Instead you should leverage other types to accomplish the same thing; for example Rc<T> can be used for things like linked-lists or trees. Also, have a look for libraries that might do this work for you, as these are very easy to do wrong.<p>LOL, sure borrow-checked reference counted pointers that can't equal null to mark the beginning or end of a chain are exactly what I am looking for when I want to build a linked list or tree. Why are you like this, Rust?
The author explained the ownership and move semantics, but <i>NOT</i> why it "click" for him/her.<p>I understand what the claims advantages of Rust are, but I can't understand those cult-like passions.
The example:<p><pre><code> This does not work in Rust. But the counterpart in C kind of does:
int &p_a = 0x100;
int a = \*p_a;
</code></pre>
Is not valid C.
I wished rust looked less ugly. It sounds like a fascinating language. But swift seems so much more beautiful. Rust imo seems the ugliest of the recent languages.