If you had to delete a topic/section/chapter, what would it be?

[carols10cents]

What knowledge have you never used again? What was most boring? What part made you whine "ugghhh when am I ever going to use this in real life?!?!"

[JosephTLyons]

What would be the purpose of removing content, to make it easier to maintain?

[carols10cents]

The print version of the book is 1.25"/3cm thick and weighs 2.4lb/1kg. I want to be sure all the content is pulling its own weight (pun intended)!

We're starting work on a new print version to go with the 2021 edition, and we have the opportunity to make large changes. There are some parts we'd like to add, so I want to make sure we also think about removing cruft and parts that aren't as useful.

[steveklabnik]

Making maintenance easier is a benefit, but IMHO not the primary reason.

Rust folks often say "oh yeah, you can learn Rust, go read the book!" and then get handed a 500+ page book. That is... intimidating. I'm reminded of this:

Are our readers best served by an append-only log of features? Are there areas we spend too much time on, and areas we don't spend enough time on? Could we get the same points across in less time?

Also, the first edition of the book (the "second edition" for those of you who have been in this game far too long) was 540 pages printed. The 2018 edition was 500 pages. Those 40 pages were mostly more advanced features that had lost their motivating examples; for example, 'a: 'b is almost unnecessary in today's Rust. So we cut describing that feature. There may be more things like that that we could in theory cut.

There's also things that we can or must expand upon, and so making some room for them might be good. For example, we need to cover async. It's important. It's not going to be a one-page thing. Is simply adding it the right call?

[labbott]

I think what I would want is two parts: Rust fundamentals and a Rust Cookbook showing how to do more advanced things. Parts I would put in the cookbook are the testing chapter(s), cargo, concurrency, iterators, object oriented programming, smart pointers. I might consider dropping the collections chapter as it seems like something that could be supplemented by the rust docs vs a more verbose written explanation. The differentiator is what is teaching me core Rust concepts vs what are more Rust idioms. I'm also coming at this from an audience of me, someone who had a good deal of C knowledge and decent object oriented knowledge. An example of a really good chapter for me was the one explaining ownership and the borrow checker.

[smklein]

FWIW, I really like all the content in the book, so any subsequent suggestions I make have the caveat "I still like this material, and it's definitely useful somewhere".

The ordering of the book oscillates a bit between "language fundamentals", "standard library fundamentals", "projects", and "tooling". I understand the line is blurred, but IMO it has a major impact on reading flow for someone figuring out how to navigate the material, especially when it's new.

• Chapter 1 is a mixture (which is kinda necessary for install / setup)
• Chapter 2 is a project
• Chapters 3-6 are language fundamentals (and they're great stuff)
• Chapter 7 is a bit of "language fundamentals" and "tooling" - IMO package management, crates, and modules are especially relevant when interacting with large projects that have dependencies, but it's kinda odd to place this between "enums" and "collection types", both of which are understandable for a newbie who is (as an example) playing with rust from the playground, or a single file.
• Chapter 8 is "standard library fundamentals"
• Chapter 9 is "standard library fundamentals" (though more on the "core" side of things, so a bit closer to "language fundamentals")
• Chapter 10 is "language fundamentals"
• Chapter 11 falls into a similar bucket as chapter 7 - testing is a core concept of rust, but IMO more on the "tooling" than the language/syntax side of things.
• Chapter 12 is a project
• Chapter 13 is "standard library fundamentals"
• Chapter 14 is "tooling"
• Chapter 15-16 are "standard library fundamentals"
• Chapter 17 is kinda "language fundamentals", though it overlaps with chapter 10's discussions of traits. More of a "design-pattern" type of thing.
• Chapters 18-19 are "language fundamentals"
• Chapter 20 is a project

TL;DR:

• I think I'm agreeing with what @labbott said about "core Rust concepts" vs "Rust idioms". The Rust idioms are useful, but there are many - which ones make the cut? Why OOP and not other stuff?
• I think a lot of the "standard library fundamentals" could potentially be moved out of the book. Might be an interesting opportunity to teach folks how to search for / read the (very well written!) rust documentation for libraries (not in a mean "RTFM" way, but in a genuine "here is our advice on how to navigate the docs to learn about something new" way). The collections chapter, iterator chapter, and smart pointers chapter stand out as opportunities for this - IIRC, they are also concepts where I quickly needed to dig into rustdocs to use them in real code.
• It might help to relocate/condense some of the related concepts. As an example, chapter 7 and 11 are very closely related (you can't write tests without some mod, and 11.3 even discusses the similar concept of breaking up tests into separate files/directories).

[oconnor663]

Personally I'm not sure I've ever used Rc or RefCell in non-teaching code. I'm not sure I've even seen non-teaching code that uses them. (I know it's out there, just not in the projects I've worked with.) For me, the overwhelmingly common case for both smart pointers and interior mutability is Arc<Mutex<T>>. When I'm teaching Rust to folks who already know what threads and mutexes are in general, I find it easiest to start there, and to only introduce Rc/RefCell/Cell later as more advanced examples of what Send and Sync mean and what interior mutability is capable of. On the other hand, if the audience doesn't know what a mutex is in general, maybe the flow here is totally different?

[lf-]

I would personally delete the section on object safety and replace it with a link to the reference. I believe it's impossible to satisfy the competing goals of making it complete enough to be useful while also keeping it simple enough to fit the style of the book, given the previous discussions on requests to change it. Currently it's doing more harm than good in my view. It's confused two friends so far who have hit object safety conditions, in both cases conditions related to the receiver type, that aren't addressed in it, and it doesn't say "the conditions include but are not limited to, see the reference for full details" or similar, so it's unclear to readers that it's incomplete.

[JakubKoralewski]

For what it's worth I have never even taken a good look at the final project. There's lots of open source Rust code and you can read whatever aligns with your interest.

[Takashiidobe]

(Disclaimer: I'm new to rust.)

I think the final project could be revised to use async. I think it would tie everything together at the end, and be a good final project. That being said, will it use async-std or tokio, or will the book explain the async traits and implement everything from scratch?

Chapters I thought could be improved: Chapter 2 has us programming a guessing game and bringing in concepts from later chapters (traits, match, crates). I was confused why this wasn't later (maybe after chapter 6, enums and pattern matching), since it uses concepts from later chapters. Since this has some overlap with chapter 7's project, I think one of these can be removed in favor of the other, or combined in some way.

I think chapter 6 (Enums and pattern matching) can be merged with chapter 18 (Patterns and Matching), since they talk mainly about pattern matching.

I think chapter 17 (Object oriented features of rust) should be earlier in the book, since fearless concurrency talks about traits (chapter 16), and traits are fairly important/unique to rust (like the ownership chapter).

[meltyness]

Some of the Chapter introduction sections are basically re-motivated again by the individual sections. Chapter 7 isn't pulling its weight. I still haven't figured out module pathing, and just permute until something works. Chapter 18 doesn't introduce very many new details, it might be best to shard that out all the way back into chapter 2 when match was introduced. Namely, for me it exposed:

1. Range match
2. Or match
3. match guard
4. @ / struct matching

It just seems like it would be feasible to introduce all these different flavors of pattern matching on-the-fly, rather than devoting a whole chapter to it.

I think that I'm in the target audience, but the sections where my "highlighting" suprising, bewildering, or facts I needed to carefully scrutinize waned: 3.3 Functions 3.4 Comments 12.6 Writing Error Messages to Standard Error Instead of Standard Output 17.3 Implementing an OOP Design Pattern (granted my entire programming background has been borne in OOP)

Overall though, it was easy to get a good rhythm in teaching myself the lessons, and following along with a minute few exceptions, and I don't really think the book is too long at all.

[JosephTLyons]

Chapter 7 isn't pulling its weight. I still haven't figured out module pathing, and just permute until something works.

I know the Steve worked hard on this, but I agree. Rust module stuff is just confusing, no matter how well you explain it (IMHO). I definitely don't think removing it is the best option, but I'm not sure how it can be improved either.

[karencfv]

Hi there! Thanks for opening up these questions to the broader public 🙇‍♀️

Bit of background from me: I am new to Rust and finished the book about 6 weeks ago. For the past several years I have been working predominantly with Go, and worked with a few other languages some years before that. I am also a non native English speaker :)

I found the book very digestible and easy to follow along. I didn't once have to go looking on google (urban dictionary?) for some idiom I wasn't familiar with. Thank you for this!!! It's very much appreciated.

I found everything on the book useful. If I had to think of parts that I might have skimmed over a bit or felt that weren't directed towards a person with a similar background as me, it would be the following:

• At times some parts of the book felt directed towards people with a background in Ruby or JavaScript.

• I was somewhat confused as to why there was a chapter on OOP if Rust is not a fully OO language. Having not worked with an OO language for quite a while now, this line of the book made me want to just skim over this chapter a bit:

  We’ll then show you how to implement an object-oriented design pattern in Rust and discuss the trade-offs of doing so versus implementing a solution using some of Rust’s strengths instead.

  I would have probably found it more engaging if the book only focused on the idiomatic alternative implementation that didn’t use the state pattern, and omitted talking about the state pattern altogether. Given the book mentions this pattern does not make use of Rust's strengths.

As for the sections that I think could be expanded a bit, I would definitely go for concurrency. I would have liked to read more and have more exercises on that subject.

[ibraheemdev]

There have been hundreds of beginner asking basic module system questions on the rust discord servers, after reading the book. These two articles to a very good job of explaining it. The idea of declaring and then importing from a root is confusing to many people. I also think the "old" mod.rs way is easier to teach to people, because then you can use an explanation like (this has helped many people):

mod foo;

// becomes (evaluated at compile-time)
mod foo { if "foo.rs".is_file() { include!("./foo.rs") } else { include!("./foo/mod.rs") } }

Either way, I think that the current explanation could be improved.

[ericsampson]

agree that the "rust-modules-vs-files" post was very helpful. I hadn't seen the second one yet, but bookmarked... :)

[JosephTLyons]

Curious if anything was ever decided on here.

[n1trux]

The ordering of the book oscillates a bit between "language fundamentals", "standard library fundamentals", "projects", and "tooling". I understand the line is blurred, but IMO it has a major impact on reading flow for someone figuring out how to navigate the material, especially when it's new.

As someone new to the language, I agree. There is multiple books and references which all have a part of the information, but I have to jump around between the Rust Book, the Reference and Rust By Example to figure something out.

I would have expected the language fundamentals to be introduced first and the example or project coming afterwards (as explained in #3736).