
Next Iteration of “The Rust Programming Language” Book - nanxor
https://rust-lang.github.io/book/
======
mevile
People should know this isn't ready, and they should continue to use the
current book. Chapers like this are just notes:

[https://rust-lang.github.io/book/ch17-00-oop.html](https://rust-
lang.github.io/book/ch17-00-oop.html)

This doesn't help anybody. Continue to use the rust book at:

[https://doc.rust-lang.org/doc/stable/book/](https://doc.rust-
lang.org/doc/stable/book/)

~~~
carols10cents
We actually had someone say that the new version is so much better than the
old book, even though it's incomplete, that it's like a medical trial where
the treatment is going so well it'd be unethical to keep people on the
placebo. A bit hyperbolic, yes, but so is "this doesn't help anybody".

~~~
jventura
Although I have some years of practice in programming, I always prefer to
learn new languages using some kind of practical tutorial that introduces the
topics as we go along. I've just finished the guessing_game tutorial and
really understood the general idea of cargo, externs, associated functions,
etc.

Congratulations, and I hope that the rest of the book is as practical on
introducing the following concepts as the tutorial was for me..

~~~
Graziano_M
I like Rust, but I was a lot more impressed with how Go introduces it.
[https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)

------
Synroc
I had tried running Rust for a few months now, but it didn't really clicked
until I went through this book.

Thanks to the great explanations of the concepts of rust, the helpful
exercises and examples, I have not only since been able to contribute to the
RustLang, but also am in the process of a PR for Servo, created a website
using rocket.rs, and started using Rust at work.

It's definitely true that the initial hump of learning Rust was more intense
than other languages such as Python, but this book helped to alleviate a lot
of the initial pain.

Thanks carols10cents & steveklabnik!

~~~
mevile
Which book did you read this one or the stable one:

[https://doc.rust-lang.org/doc/stable/book/](https://doc.rust-
lang.org/doc/stable/book/)

They aren't the same.

~~~
Synroc
This unfinished one. Despite being unfinished, I still preferred the content
over the current official one.

------
AsyncAwait
Another excellent book is "Programming Rust"[1], especially if you already
know C/C++

1 -
[http://shop.oreilly.com/product/0636920040385.do](http://shop.oreilly.com/product/0636920040385.do)

~~~
msbarnett
I've been reading the early access version for a while now, and it is
_excellent_. I hadn't had much luck with the "official" documentation,
previously.

Jim Blandy's writing is an exemplar for good teaching technique, and this book
is shaping up to be the go-to recommendation for learning Rust, in my opinion.

~~~
vu3rdd
I have been reading it as well. For my taste, it is a bit too verbose.

I like to see something along the lines of the K&R book or the GoPL book. I
was hoping that "Programming Rust" is such a book, but I was disappointed. And
(may be it is just me) I like to see exercises in Programming books.

~~~
fnord123
C an Go are pretty concise languages so they lend themselves to K&R and GoPL.
Rust is a big language (like C++) and is still changing quite a bit so I don't
think you'll get a similar tome in the near future. (imo)

------
lacampbell
I'm reading the section on ownership. Valgrind usually thinks my 'modern C++'
code is leak free, and when it complains I understand why, so I'm not a
complete stranger to systems programming. But for whatever reason I have
always run into a brick wall with rusts strange compiler messages regarding
lifetimes.

I read the previous books bit on ownership. I'm not sure if this new version
is better written or I've come across this stuff so many times that it's
starting to make sense to me through pure attrition - but the picture does
seem clearer to me. Particularly the "Ownership and Functions" bit.

I'll definitely make use of this next time I think I have a rust shaped
problem. Whether that will put me over the edge into being a rust user will
remain to be seen (I have my reservations about lots of other stuff), but I
appreciate they're really trying with the documentation side of things.

~~~
cgh
Lifetimes can be confusing as hell, especially declaring them correctly. It
looks like section 10.3 in this new book improves things.

~~~
cpeterso
As a C++ programmer, I understand ownership and borrowing, but I find the
lifetime syntax impenetrable. It clutters the code with annotations that seem
like they could be deduced by the compiler.

For example, a variable's lifetime is relative to another variable or
function. Why must we create a placeholder name like 'a instead of referring
to the other variable by name? Take this example from section 10.3:

    
    
      fn longest<'a>(x: &'a str, y: &str) -> &'a str {
          x
      }
    

Why couldn't we write it as something like the following?

    
    
      fn longest(x: &str, y: &str) -> &'x str {
          x
      }
    

Or instead of requiring lifetimes everywhere, the compiler could use
conservative defaults but allow optional lifetime annotations to reduce the
lifetime if needed or to release memory sooner. For example, in this struct
from section 10.3, why is 'a necessary when config is a non-mut reference and
thus must outlive a struct App instance? There is a Rust issue filed for this:
[https://github.com/rust-lang/rfcs/issues/1532](https://github.com/rust-
lang/rfcs/issues/1532)

    
    
      struct App<'a> {
          name: String,
          config: &'a Config,
      }

~~~
Manishearth
The Rust community prefers explicitness in many cases. We already have
lifetime elision for simpler things. Both of these cases in your comment have
been extensively discussed and decided against.

The reason why the former is not done is because it makes the signature
dependent on the body. This means that changing some code could potentially
change the signature of the function, which is the kind of silent magic that
folks would prefer to be explicit. Also, as the function gets larger, this is
harder to deduce by looking at the code. The current elision rules all operate
on the signature, so you only need to look at the signature to figure out the
lifetimes, elision or not.

The latter is way more controversial. The reason there is similar; folks want
it to be obvious from the type name that it is a borrowing type, and changes
to the internals shouldn't magically change the signature without an explicit
acknowledgement.

Even type arg lifetime elision was controversial. Currently, in Rust, you can
write a function like `fn foo(x: &u8) -> Foo`, where `Foo` is actually
`Foo<'a>`, and the compiler inserts the lifetimes in the right places. When
this was proposed there was a good chance that it would not happen (though as
you can see it did happen). So the status quo on lifetime elision is
_probably_ not going to change in my opinion, given how hard it was to make
the last one happen (of course, you have the "overton window" of acceptable
implicitness gradually shifting due to that change, so it might after all)

To me personally, this explicitness is a minor annoyance when dealing with
simpler stuff, but is invaluable in codebases making heavier use of lifetimes,
like rustc (which avoids reference counting, even though compilers generally
need a lot of tricky sharing). And ultimately, I appreciate it even in
codebases with fewer lifetimes; I don't like having to peek at a function's
code to understand how it's supposed to be used.

------
purple-again
Sigh. Looks like it's time for round 5 of time to learn Rust(my personal
failing, not meant as a slight against the language at all). Has the pace of
sweeping changes to the language slowed down in the past year?

I rode the Ember train from 1.4 to now and it was an extremely ehausting
process to get to 2.0 with nearly every version requiring frustrating
architectural rewrites. The upgrade from 2.0 to 2.8 took like 15 minutes and
didn't require a single major refactor. I'm not trying to switch context away
from a discussion of Rust, that's just for example purposes of stabilizing.

I found myself struggling to find guides that still worked as written and I
was looking at guides because I failed to become competent from the Rust book
and Rust by example alone so I wasn't able to diagnose the upgrade path for
the content. This has stopped my learning dead in its tracks every time.

To be clear, I have no CS background or functional programming experience so
I'm not the target audience and I don't mean any this as a slight against the
language.

~~~
careersuicide
As others have said; Rust is very stable now.

I started trying to learn Rust at 0.7 (maybe a bit earlier, I can only find
references to 0.7 in a few projects of mine). Boy howdy did that feel like an
exercise in futility. I would set it aside for 3 weeks, revisit it, and find
entire language constructs had been removed. I complained about this and Steve
Klabnik graciously reminded me that it was a work in progress and that the
work was being done out in the open intentionally. I really can't thank him
enough for that since it caused me to go from frustrated to sympathetic. As a
result I decided to not write the language off. And I'm glad I didn't. After
things slowed down around the betas for 1.0 it became clear that Rust was
worth learning. I haven't had a chance to use it professionally, but for
personal projects I find myself reaching for Rust for problems that would have
caused me to have reached for C in the past.

Also, Google has gotten significantly better about returning current and up to
date information on Rust as well. Around 2013-2014 my biggest gripe was that
I'd search for how to do something only to find advice that was woefully out
of date. I haven't had that experience in well over a year now.

~~~
nickik
I started to write a VM in Rust and every weekend, when I managed to get some
time for work it would usually no longer work and the reason for it had to be
found in some mailing list or commit message.

I had to stop doing that and rewrote it in C.

'Fortunately' we had some other problems as well but Im still hopeful that
Rust is the language you want to use for this in the future.

~~~
swsieber
I think it is. Especially if you keep your code in a public repo, any breaking
changes (probably just tweaks as opposed to huge features that break stuff),
will probably have a pr filed via cargo.

From what I understand, the rust team has scripts that crawls the repos and
compiles everything looking for usages of some feature being used that's going
to break in the next release, and they will issue a pull request to fix those.

~~~
steveklabnik
It's more subtle than that. For most things, we guarantee no breakage at all,
and we do runs like that (though not against github, but against crates.io) to
verify we haven't accidentally broken something.

For stuff that we are allowed to change, but might cause breakage, we will try
to find stuff and send PRs.

But the default and our intention is zero breakage as much as possible, not
just "we'll fix it for you". We'd guarantee absolutely none but it's not
actually possible in a statically typed language, so we have to go with
"effectively none."

~~~
charlieflowers
Automatically filed pull requests against my github repo would be amazing!

Actually, you all looking through crates and sending PR's is pretty impressive
in itself.

------
Dangeranger
This book has been hugely helpful for me to get started in Rust. I've been
following since the original "Rust for Rubyists" from Steve Klabnik.

Steve if you are listening, thanks for putting all the hard work into the
original book, the revision as The Rust Programming Language, and this most
recent revision.

~~~
AsyncAwait
Thanks to Steve and also carols10cents for this excellent revision.

~~~
steveklabnik
Thanks to you both! And very seriously, this edition could not have happened
without carols10cents. I am exceedingly grateful to have her as a co-author.
While the original book was largely me, this edition is very much indebted to
her work.

------
rdtsc
Thanks for sharing, very nice work.

Was drawn to the "An I/O Project" section. Everyone learns differently, and I
like to learn by example, that's why I often scroll to the bottom of the man
page to see example before reading the description of a new command.

So I'd like to see more stuff like that. Anyone know of a good Rust
"Cookbook"? I found a few but there were just started with only a few
examples.

Also in my case, I can breeze through the start section pretty quickly, I
understand the ownership basics, traits and generics separately. But seeing
structs, traits, lifetimes and generic together it feels like hitting a wall.
I'd welcome a resource that sort of uses lots of examples with combinations of
those things.

~~~
steveklabnik
There isn't really anything big yet like that; I'd love to see one!

------
proctor
I have found this book to be an excellent resource. Also I have been
supplementing it with the oreilly book "Programming Rust" (early release at
this point) which has also been great.
[http://shop.oreilly.com/product/0636920040385.do](http://shop.oreilly.com/product/0636920040385.do)
I have had very little experience with C style languages in the past and am
mostly scripting until recently.

------
ohazi
This new book isn't finished yet, is it? If I remember correctly [0], there
were several more chapters to go, and a likely timeline of months...

[0] [https://github.com/rust-lang/book/issues](https://github.com/rust-
lang/book/issues)

~~~
steveklabnik
> a likely timeline of months...

I am forbidden by my coauthor to prognosticate about due dates, but let's just
say that... well, I won't say anything ;)

I'm almost done with the first draft of chapter 15.

~~~
carols10cents
> I am forbidden by my coauthor to prognosticate about due dates

TRUE FACT. Everyone here knows how hard it is to estimate, we'll let everyone
know once it's done instead :)

------
steveklabnik
Both carols10cents and I, the primary authors, are reading this thread. Happy
to answer any questions other than "when will it be done," as estimations are
hard ;)

~~~
TheCoreh
Are you interested in translating the book to other languages? Is such a
project already underway? I can help with Portuguese

~~~
carols10cents
Yes we are! There's someone working on Vietnamese [1]. It's a bit blocked on
mdbook support [2], but the translation part could start before that's done.
Chapters 2, 3, 4, and 6 are effectively "frozen" for print at this point [3]
so they'd be the place I'd recommend starting first!

[1] - [https://github.com/rust-lang/book/issues/375](https://github.com/rust-
lang/book/issues/375)

[2] -
[https://github.com/azerupi/mdBook/pull/200](https://github.com/azerupi/mdBook/pull/200)

[3] - [https://github.com/rust-lang/book/projects/1](https://github.com/rust-
lang/book/projects/1)

------
beebob
I'm currently starting to learn rust (previous java and go developer). But at
the moment it feels like the good old times where I was developing with an
editor and api doc side by side.

What is the current editor of choice for rust projects? I tried intellij-rust
and atom with the racer plugin. Both seem to be in a somewhat early stage of
development regarding the auto completion.

Regarding the book: I like it. Has been a long time since I had fun reading
such a book. With most languages I just learn by googeling one problem after
another until it clicks ;)

~~~
steveklabnik
IDE integration is a big theme of this year, so this will change rapidly over
the next few months. We aim to provide plugins for everything, pretty much.
Specifically, we're implementing Microsoft's "Language Server" interface, so
anything that can interface with it will work well,
[http://langserver.org/](http://langserver.org/) has the full list, I believe.

Glad you liked the book! :)

------
amelius
I wish they had a chapter covering how to efficiently implement graph
algorithms without ending up in a struggle with the borrow checker.

~~~
wscott
Have you read this one yet? [http://cglab.ca/~abeinges/blah/too-many-
lists/book/](http://cglab.ca/~abeinges/blah/too-many-lists/book/)

It touches on the issues you are implying.

------
vu3rdd
Happy to see the modules chapter and the testing chapter early enough in the
book.

Thanks. The new format looks a lot better, IMHO.

------
jayflux
I noticed there's no mention of Boxes. Do we still need to know about them? Or
are they going away?

------
manaskarekar
Echo all the positives about the book. Thank you.

I hope the quick link to the rust playground in the sample code stays around.

Also curious, is this supposed to be reflected on Rust Stable at
[https://doc.rust-lang.org/stable/book/](https://doc.rust-
lang.org/stable/book/)

~~~
carols10cents
<3 You're welcome!

The new revision of the book is using mdbook, which hasn't yet implemented
playground support [1].

An RFC has recently been accepted to start the infrastructure of featuring the
new book (and other resources) on doc.rust-lang.org/book, but the
implementation isn't done yet. Soon!

[1] -
[https://github.com/azerupi/mdBook/issues/29](https://github.com/azerupi/mdBook/issues/29)
[2] - [https://github.com/rust-
lang/rfcs/blob/master/text/1828-rust...](https://github.com/rust-
lang/rfcs/blob/master/text/1828-rust-bookshelf.md)

------
stirner
Hey carols10cents and/or steveklabnik, what project was the example code in
the Performance section (13.4) taken from? I'm interested in Rust and audio
and especially both of them combined.

~~~
steveklabnik
[https://ruudvanasseldonk.com/2016/11/30/zero-cost-
abstractio...](https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions)

~~~
stirner
Thanks! I looked through the FLAC spec a while ago and I thought it looked
familiar.

------
jayflux
Is it possible to make a PDF or an offline version? Sometimes i like to read
these sort of things while i'm on the train etc.

I struggled to get the current rust book working on my ipad on the train
without signal.

~~~
carols10cents
Good news! NoStarch will be printing an offline version soon ;)

Since we're concentrating on getting the text ready for print, we haven't been
able to get pdf/offline reading working yet. [https://github.com/rust-
lang/book/issues/218](https://github.com/rust-lang/book/issues/218)

~~~
jayflux
Thanks! I would absolutely love a single webpage version, that would be even
better

~~~
steveklabnik
You can click the "print" button in the upper right hand corner, which gives
you [http://rust-lang.github.io/book/print.html](http://rust-
lang.github.io/book/print.html)

~~~
dbaupp
For some reason that page has the title "Macros - The Rust Programming
Language"

~~~
steveklabnik
Weird, I'll file a bug, thanks.

------
JasonSage
Something I'm curious about is why this next iteration of the Rust Programming
Language book has been developed relatively hidden away from new folks, who
have to continue using the old book unless they stumble upon the new one
somehow.

I would think that if the content of the new book does a better job at
educating new users of the language, you would want that to be in front of
everybody as absolutely soon as possible.

With that in mind, why is the strategy to complete the new book entirely
before moving over? If the new one has such big gaps that it can't stand on
its own, why not try some gradual migration?

~~~
steveklabnik
> relatively hidden away from new folks,

We talk about it quite a bit on IRC, on Twitter, in the forums/Reddit, and
elsewhere. I've specifically put the text out in front of new people to get
feedback.

> why is the strategy to complete the new book entirely before moving over?

This is not _strictly speaking_ true, but it's been blocked on some other
things. We haven't been able to use mdBook, the tool we use for the new book,
inside the Rust repository until two days ago[1]. This was due to a number of
factors that had nothing to do with the book.

Soon[2], we'll be able to actually present both books on the website, and so
this will be messaged a bit better.

> If the new one has such big gaps that it can't stand on its own,

Well, I mean, we started from scratch. The full first draft isn't even done
yet! When's the right time for this, after one chapter is done? Two? Five?
It's a tough question, but the actual nuts and bolts of the build process made
that question moot, and now that it's 75% done by chapter count, it's all just
kind of working out.

Does that all make sense?

1: [https://github.com/rust-
lang/rust/pull/39633#issuecomment-27...](https://github.com/rust-
lang/rust/pull/39633#issuecomment-279909845)

2: [https://github.com/rust-lang/rust/issues/39588](https://github.com/rust-
lang/rust/issues/39588)

------
Oxitendwe
Does this release bring us any closer to a formal specification of Rust?

~~~
steveklabnik
This has nothing to do with the formal specification work.

------
indolering
As a technical documentation nerd, I hope we can get a rudimentary JS (or
WASM) IDE and compiler worked out and A/B test everything on Khan Academy for
version 3.0. One impossible task at a time : )

~~~
ZoFreX
For the IDE part is this the sort of thing you mean? [https://play.rust-
lang.org/](https://play.rust-lang.org/)

What do you mean by A/B testing it on Khan Academy?

------
golemotron
Who is the author of this book?

~~~
steveklabnik
Myself and carols10cents.

We have also accepted small fixes and such from almost 70 other people as well
[https://github.com/rust-
lang/book/graphs/contributors](https://github.com/rust-
lang/book/graphs/contributors)

------
makai
I like the old book much more, especially the style sheet.

