https://rust-lang.github.io/book/ch17-00-oop.html
This doesn't help anybody. Continue to use the rust book at:
Congratulations, and I hope that the rest of the book is as practical on introducing the following concepts as the tutorial was for me..
I would definitely recommend this to rust beginners, and tell them to just use the old book where the new isn't complete.
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!
https://doc.rust-lang.org/doc/stable/book/
They aren't the same.
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.
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 struct App<'a> {
name: String,
config: &'a Config,
}We decided to do it this way so that you can write real Rust code without going "what is that syntax"; you don't need to have a full understanding of the more exotic aspects of lifetimes to write useful code in Rust.
It's to easy to go though the current tutorial and think "wow, this is easy and makes sense" only to come completely undone when you try to do something.
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.
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.
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.
Up until Rust 1.0 in the spring of 2015, my Rust code broke once or twice a week. Since then, I've had zero breakage.
Absolutely, Rust has been stable since 1.0 released in May 2015 with a promise of backwards compatibility and has largely upheld that promise.
I dread the day I no longer see progress. I suspect it's also about the time I'll really find programming no longer fun.
It shouldn't have been the standard library though. If it was, that'd be a serious bug! If you do figure it out, and it is the standard library, please file a bug. And if you need any help, feel free to reach out. I'm here to help.
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.
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.
Didn't read the rest of the book, so I don't know if there are more tutorials, but I learn better with that because it clearly shows what one can do with the language.
More Lifetimes
Lifetimes that depend on other lifetimes
'a: 'b stuff: subtyping
Higher ranked trait bounds
for<'a>
Needed for closuresI 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.
TRUE FACT. Everyone here knows how hard it is to estimate, we'll let everyone know once it's done instead :)
[1] - https://github.com/rust-lang/book/issues/375
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 ;)
Glad you liked the book! :)
It touches on the issues you are implying.
Or just use RefCell, deferring the borrow checking until runtime.
Another strategy could be to give every node an explicit ID, and then have a mapping ID -> node. Every else you just refer to the nodes by their IDs.
Thanks. The new format looks a lot better, IMHO.
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/
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 [2] - https://github.com/rust-lang/rfcs/blob/master/text/1828-rust...
I struggled to get the current rust book working on my ipad on the train without signal.
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
Eventually we'll provide a PDF of this, but the HTML should work offline. This edition might need some tweaks first; it's a priority for me though.
Ah... I see. You have to run "rustup component list" and it'll print out a whole bunch of things that you can install like cargo and rustc and 44 different versions of std and also somewhere in there the docs. And then you have to know that that the thing you have to pass to "rustup component add" is not the string you get out of "rustup component list" (something like "rust-docs-armv7-unknown-linux-gnueabihf") but in fact just "rust-docs". And none of this seems documented anywhere in the help text in rustup itself, at least not the 1.0.0 version that I have.
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?
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...
Because it is not done yet.
What do you mean by A/B testing it on Khan Academy?
We have also accepted small fixes and such from almost 70 other people as well https://github.com/rust-lang/book/graphs/contributors
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.
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.
I wish there were 50 books on Rust. :)
Ha, well that's certainly true, as evidenced by your first sentence, I think, you meant complEment!