4 ms·
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 boo
by 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 agoI 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 agoThe 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 agoYeah, 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...
- akiselev 10y agoThat chapter is where I got that phrasing but it's literally the chapter right before the one on the FFI, an advanced topic with unsafe code! In the bottom third of the book. I'm talking about scattering bits of that chapter all over the book, including the first concrete language chapter on Variable Bindings. There's over thirty chapters between "Ownership" and "Choosing your Guarantees" which I think creates massive friction for new developers who never even get to that chapter before getting frustrated and giving up.
- steveklabnik 10y ago> the chapter right before the one on the FFI The "Effective Rust" section of the book is in no particular order; each chapter is self-contained and can be read without the others. That is one reason why the new book does not have this chapter, though. It's organized differently.
- akiselev 10y agoYeah the new book looks much better (Although it's hard to evaluate onboarding since I'm past the beginner stage). Thank you for all your work! I don't mean to be critical, I'm just very much invested in Rust's mass adoption :) Is there any discussion on the genesis of the new book I can find? I'm curious to see the thought process behind the rewrite.
- fny 10y agoSee "Learning Rust with Entirely Too Many Linked Lists" http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/