Flattening Rust’s learning curve
corrode.dev
Flattening Rust’s learning curve
1–10 of 405 posts
Re: Flattening Rust’s learning curve
#2> Treat the borrow checker as a co-author, not an adversary
Why would I pair-program with someone who doesn’t understand doubly-linked lists?
Re: Flattening Rust’s learning curve
#3> Treat the borrow checker as a co-author, not an adversary Why would I pair-program with someone who doesn’t understand doubly-linked lists?
I'd rather pair program with someone wary of double-linked lists, but is really hot on understanding ownership than the other way around.
Re: Flattening Rust’s learning curve
#4Does anyone still have trouble learning Rust? I thought that was kind of a 2015 thing
Re: Flattening Rust’s learning curve
#5I thought it was quite manageable at beginner level…though I haven’t dived into async which I gather is a whole different level of pain
Re: Flattening Rust’s learning curve
#6> Treat the borrow checker as a co-author, not an adversary Why would I pair-program with someone who doesn’t understand doubly-linked lists?
For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1]
It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes, but Rust's ownership rules don't easily allow for multiple owners of the same data or circular references.
You can implement one in safe Rust using Rc> (reference counting with interior mutability), but that adds runtime overhead and isn't as performant. Or you can use raw pointers with unsafe code, which is what most production implementations do, including the standard library's LinkedList.
Re: Flattening Rust’s learning curve
#7I thought it was quite manageable at beginner level…though I haven’t dived into async which I gather is a whole different level of pain
Async and the "function color" "problem" fall away if your entire app is in an async runtime.
Almost 90% of the Rust I write these days is async. I avoid non-async / blocking libraries where possible.
I think this whole issue is overblown.
Re: Flattening Rust’s learning curve
#8> Treat the borrow checker as a co-author, not an adversary Why would I pair-program with someone who doesn’t understand doubly-linked lists?
So that you learn that loaning is for giving temporary shared^exclusive access within a statically-known scope, and not for storing data.
Trying to construct permanent data structures using non-owning references is a very common novice mistake in Rust. It's similar to how users coming from GC languages may expect pointers to local variables to stay valid forever, even after leaving the scope/function.
Just like in C you need to know when malloc is necessary, in Rust you need to know when self-contained/owning types are necessary.
Re: Flattening Rust’s learning curve
#9Does anyone still have trouble learning Rust? I thought that was kind of a 2015 thing
The thing is, once you internalized the concepts (ownership, borrowing, lifetimes), it's very hard to remember what made it difficult in the first place. It's "curse of knowledge" in some sense.
What's changed since 2015 is that we ironed out some of the wrinkles in the language (non-lexical lifetimes, async) but the fundamental mental model shift required to think in terms of ownership is still a hurdle that trips up newcomers.
Re: Flattening Rust’s learning curve
#10Does anyone still have trouble learning Rust? I thought that was kind of a 2015 thing
The thing is, once you internalized the concepts (ownership, borrowing, lifetimes), it's very hard to remember what made it difficult in the first place. It's "curse of knowledge" in some sense. What's changed since 2015 is that we ironed out some of the wrinkles in the language (non-lexical lifetimes, async) but the fundamental mental model shift required to think in terms of ownership is still a hurdle that trips u…
100%. Newcomers still struggle a bit, especially if they've never used C/C++ before.
A good way to get people comfortable with the semantics of the language before the borrow checker is to encourage them to clone() strings and structs for a bit, even if the resulting code is not performant.
Once they dip their toes into threading and async, Arc> is their friend, and interior mutability gives them some fun distractions while they absorb the more difficult concepts.