6 ms·

That's the primary problem I had with the Rust learning curve: you learn all about this great safety stuff but the documentation fails to beat into your head th

That's the primary problem I had with the Rust learning curve: you learn all about this great safety stuff but the documentation fails to beat into your head that the safety switches are right in front of you. The chapters on variable bindings and mutability should both start by introducing RC<RefCell<>> and the first couple of introductory chapters should use only unsafe code (I'm only half joking on both points). For all the emphasis on how the extra safety prevents common bugs and makes life easier, little is put on how to actually tell the borrow checker that you (sorta) know what you're doing and the true power of unsafe is left for some deep dark corner. I mean, seriously, the book on unsafe Rust is called the Rustonomicon as if the memory model of the old default-unsafe-unless-you're-Dennis-Ritchie languages is some Lovecraftian horror brought on because of our thirst for the cursed FFI. Meanwhile, Rust's damn near magic (at least for me, a non-functional systems mortal) affine type system, which can eliminate many logic bugs and massively increase code reuse, is all but forgotten. The type system is at the core of Rust's entire memory safety but you need to read dozens of scattered blog posts and projects, and the standard library docs, to start to get a feel for how to move from OOP to trait based composition and lifetimes. In aiming for simplicity, most docs fail to show in practical settings how you can use Rust's type system to redesign your architectures in natural ways that completely reframe the process of writing code, making it easier to port ways of thinking and love the borrow checker. Sorry, that was a colorful rant. Teaching a new paradigm is tough and the Rust docs team have done a great job. As the language and community mature, better and better pedagogical practices will emerge and introductory material that approach the language from all angles will grow.

deleted 10y ago
[deleted]
tatterdemalion 10y ago
You're not wrong. I think the reality is that the design patterns for using Rust are still emerging from our shared experience; trying to write that sort of book would be putting the cart before the horse.
- akiselev 10y ago
  I don't think it should be a whole new book, just a few sections in the current one. A good start could be a "Down the Rabbit Hole" red section sprinkled through out (like all those side boxes in textbooks and programming books) that emphasises that all of this safety can be negotiated with the compiler through the use of native (implemented in the standard library in Rust) types and links to the relevant chapters in a new window. For example, when introducing ownership and borrowing rules there could be a quick blurb about RC, RefCell, and other types that let you pick and choose which guarantees you want the compiler to enforce and how "unsafe" is just a keyword to tell the borrow checker to buzz off for a second. Reemphasize it a couple of times in the same chapter and have a small chapter on how to debug corner cases. The point is to plant ideas in the reader, little factoids that may help things click or at least give them a starting point they may remember when they get frustrated by the compiler.
  - AsyncAwait 10y ago
    The thing is, types like Rc should be avoided if possible in idiomatic Rust, it should not be: "Oh my code doesn't compile, that means I need to use Rc", this is because most of the time it is you who made a mistake rather than the compiler.
    - akiselev 10y ago
      Yeah, sure, when you already know idiomatic Rust. The point is that many developers never even get close to understanding the borrow checker, let alone writing honest-to-goodness idiomatic Rust. This can be improved by showing them the unidiomatic stuff that they can use to suspend or shift guarantees. Besides, unwrap() is also terrible in this regard but it's the single most used feature in tutorial code. You need to teach someone Rust before they can learn idiomatic Rust.
  - steveklabnik 10y ago
    > other types that let you pick and choose which guarantees you want the compiler to enforce The current book has a chapter with a title that's almost literally this: https://doc.rust-lang.org/stable/book/choosing-your-guarantees.html https://doc.rust-lang.org/stable/book/choosing-your-guarante...
acqq 10y ago
> and the first couple of introductory chapters should use only unsafe code (I'm only half joking on both points) It's really at least half-true. As far as I understand the libraries of Rust itself can't have everything written in "safe" code. The hard part is to win the potential programmers to use the safe code as much as they can but to understand where the limits are. And that is the hardest thing to do as a lot of people prefer simplifications the kind of "everything must be done the X way" etc. I call that a "religious programming" approach and the programming world has it in immense amounts.
- akiselev 10y ago
  > As far as I understand the libraries of Rust itself can't have everything written in "safe" code. You can't express everything in safe code but wrapping an unsafe API into a safe one is relatively easy with Rust's type system. For example, typemap [1] allows you to have a unsafe hash map of types with any key type to any value through a safe wrapper that uses associated types to enforce the data structure invariants at compile time. Given a bunch of types T, for example, you can have a single safe map containing all of the mappings of Event<T> to Vec<T>, Handlers<T> to HashMap<T, FnMut(T)>, and T to &T, etc, even though transmuting random bits of memory is the definition of unsafe. [1] https://github.com/reem/rust-typemap https://github.com/reem/rust-typemap
  - acqq 10y ago
    I've never disputed that. This duality (higher level allows safe abstraction of the low level) existed since the higher level languages exist.
- AsyncAwait 10y ago
  > As far as I understand the libraries of Rust itself can't have everything written in "safe" code. Extremely low-level code or code that uses FFI indeed uses unsafe, this in unavoidable, but most Rust code doesn't need unsafe at all.
  - acqq 10y ago
lmm 10y ago
> For all the emphasis on how the extra safety prevents common bugs and makes life easier, little is put on how to actually tell the borrow checker that you (sorta) know what you're doing Because that's the wrong attitude, and would result in just recapitulating the problems of C. C programmers arrive at Rust wanting to write C, which is understandable, but if respond by telling them how to write C in Rust then they'll never see any of the advantages of Rust and frankly may as well not bother learning it in the first place. > as if the memory model of the old default-unsafe-unless-you're-Dennis-Ritchie languages is some Lovecraftian horror brought on because of our thirst for the cursed FFI. You're saying it isn't?

deleted 10y ago

[deleted]

tatterdemalion 10y ago

You're not wrong. I think the reality is that the design patterns for using Rust are still emerging from our shared experience; trying to write that sort of book would be putting the cart before the horse.

akiselev 10y ago
I don't think it should be a whole new book, just a few sections in the current one. A good start could be a "Down the Rabbit Hole" red section sprinkled through out (like all those side boxes in textbooks and programming books) that emphasises that all of this safety can be negotiated with the compiler through the use of native (implemented in the standard library in Rust) types and links to the relevant chapters in a new window. For example, when introducing ownership and borrowing rules there could be a quick blurb about RC, RefCell, and other types that let you pick and choose which guarantees you want the compiler to enforce and how "unsafe" is just a keyword to tell the borrow checker to buzz off for a second. Reemphasize it a couple of times in the same chapter and have a small chapter on how to debug corner cases. The point is to plant ideas in the reader, little factoids that may help things click or at least give them a starting point they may remember when they get frustrated by the compiler.
- AsyncAwait 10y ago
  The thing is, types like Rc should be avoided if possible in idiomatic Rust, it should not be: "Oh my code doesn't compile, that means I need to use Rc", this is because most of the time it is you who made a mistake rather than the compiler.
  - akiselev 10y ago
    Yeah, sure, when you already know idiomatic Rust. The point is that many developers never even get close to understanding the borrow checker, let alone writing honest-to-goodness idiomatic Rust. This can be improved by showing them the unidiomatic stuff that they can use to suspend or shift guarantees. Besides, unwrap() is also terrible in this regard but it's the single most used feature in tutorial code. You need to teach someone Rust before they can learn idiomatic Rust.
- steveklabnik 10y ago
  > other types that let you pick and choose which guarantees you want the compiler to enforce The current book has a chapter with a title that's almost literally this: https://doc.rust-lang.org/stable/book/choosing-your-guarantees.html https://doc.rust-lang.org/stable/book/choosing-your-guarante...

acqq 10y ago

> and the first couple of introductory chapters should use only unsafe code (I'm only half joking on both points) It's really at least half-true. As far as I understand the libraries of Rust itself can't have everything written in "safe" code. The hard part is to win the potential programmers to use the safe code as much as they can but to understand where the limits are. And that is the hardest thing to do as a lot of people prefer simplifications the kind of "everything must be done the X way" etc. I call that a "religious programming" approach and the programming world has it in immense amounts.

akiselev 10y ago
> As far as I understand the libraries of Rust itself can't have everything written in "safe" code. You can't express everything in safe code but wrapping an unsafe API into a safe one is relatively easy with Rust's type system. For example, typemap [1] allows you to have a unsafe hash map of types with any key type to any value through a safe wrapper that uses associated types to enforce the data structure invariants at compile time. Given a bunch of types T, for example, you can have a single safe map containing all of the mappings of Event<T> to Vec<T>, Handlers<T> to HashMap<T, FnMut(T)>, and T to &T, etc, even though transmuting random bits of memory is the definition of unsafe. [1] https://github.com/reem/rust-typemap https://github.com/reem/rust-typemap
- acqq 10y ago
  I've never disputed that. This duality (higher level allows safe abstraction of the low level) existed since the higher level languages exist.
AsyncAwait 10y ago
> As far as I understand the libraries of Rust itself can't have everything written in "safe" code. Extremely low-level code or code that uses FFI indeed uses unsafe, this in unavoidable, but most Rust code doesn't need unsafe at all.
- acqq 10y ago

lmm 10y ago

> For all the emphasis on how the extra safety prevents common bugs and makes life easier, little is put on how to actually tell the borrow checker that you (sorta) know what you're doing Because that's the wrong attitude, and would result in just recapitulating the problems of C. C programmers arrive at Rust wanting to write C, which is understandable, but if respond by telling them how to write C in Rust then they'll never see any of the advantages of Rust and frankly may as well not bother learning it in the first place. > as if the memory model of the old default-unsafe-unless-you're-Dennis-Ritchie languages is some Lovecraftian horror brought on because of our thirst for the cursed FFI. You're saying it isn't?