What’s New with “The Rust Programming Language”?
words.steveklabnik.com
words.steveklabnik.com
I started looking at my Ruby programs and would focus on trying to reduce the amount of memory allocations in order to improve performance, and it worked.
Even though I don't think I am going to use Rust in a production environment soon, it taught me to think about my code in a new way. It definitely is a language that everyone should take the time to learn.
(I also agree with you with going back to Ruby; I look at my code now and go "oh no so many allocations" "oh no is this threadsafe I have no idea" :) I will still always love Ruby though. )
At this point it looks like it is just a lot noise/marketing but no real large scale deployments yet and why is this?
Lots of names that will be familiar to the HN crowd on there: Dropbox, Coursera, Habitat (Chef), Postmates, Sandstorm...
Also, Mozilla's logo is up there, but it's in Firefox now, specifically. Just a small amount of code, though hundreds of millions of users is a big deployment.
Maybe because unless you're building a new product from scratch (that fits Rust's use case), it's hard/impossible to either convince your boss or your team to switch?
Rust is working great. It's stable and reliable. I don't love Cargo, but it's still sooo much better than autotools.
I've got efficiency I need for pixel-pushing, and I'm not worried that an off-by-one error will get my servers owned.
http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz...
TRPL has proven a fantastic resource for learning Rust. I'm wondering if you have a plan for how it will track the advancement of the Rust language itself - do you intend to maintain a version of the book for major point releases of Rust, minor point releases, etc?
I wish I could cite some specific examples but I didn't keep notes, but I think I've come across a a few instances where, say, something behaved differently in Rust 1.10 versus Rust 1.12. Will the book attempt to tackle this?
In a sense, there _is_ a version for each version of the language:
* https://doc.rust-lang.org/1.8.0/book/
* https://doc.rust-lang.org/1.9.0/book/
* https://doc.rust-lang.org/1.10.0/book/
The second bit is, thanks to the stability guarantees, these days, the book doesn't really go out of date. Everything works. That said, there are sometimes new features added that it doesn't always cover; this is really tricky in general. There's an overall tension here, since it's an official project: I feel the need to be comprehensive, yet a good text is often defined just as much by what you leave out as what you put in. So the book tries to be _mostly_ comprehensive, but not totally so. So it's okay if new features aren't immediately in the book.
This also ties into Rust itself, and something the team has been thinking a lot about. With most languages, you have major releases in order to sort of chronicle the language through history: new idioms, new features, etc. With our release schedule, and no plans to make a "2.0, major breaking changes everything is different" release, we don't have that normal point to tell the story of how Rust is changing. So I can imagine that major updates to the book will happen along these same "epochs", as Rust changes over time. We're still trying to figure that all out, though. But the key is that many Rust releases aren't game-changing: only some features actually change idioms.
Finally, No Starch will be publishing the book in paper form. So there's also the question of that, but at the moment, we're mostly interested in shipping this one, but everyone is on board with _some_ sort of periodic refresh of the printed edition as well. We'll see how it goes.
Does that make sense?
EDIT ah, https://github.com/rust-lang/book clarifies this, it's a rewrite, and is not (yet) part of the main Rust repository.
In order to not trash the book while we're doing the re-write, we've moved it to a new repository, which is the one you've linked.
When the new book is ready, we will either merge it into `src/doc/book` or remove the book from the main repository and use rust-lang/book as the new official source, it's not totally clear yet which.
Also, no matter which of these two options we choose, we still plan to ship the book inside installations of Rust for offline reading, and host the book on docs.rust-lang.org.
I really appreciate all of the effort put into the documentation, tutorials, examples. It's made Rust the first language I've intentionally sought to learn in quite some time.
[0] https://github.com/rust-lang/rust/tree/master/src/doc/book
I am extremely happy to accept pull requests with typo fixes, small re-writes for clarity, and paragraphs adding more clarity.
I would prefer that for very large changes, interested parties swing by #rust-docs or #rust or email me about them first, and be okay with me doing a lot of editing before merge.
Can't thank you enough, nice work.
Or maybe it's just a nod in the direction of truth, as the author can often change the post after it is initially published, or even just change the date to be whatever they want.
August 15, 2016, for posterity's sake. :)
This couldn't have come at a better time for me. I started learning Rust in August 2015 from TRPL, but life got in the way. Now I've started up again, so I'm very excited about the documentation updates.
I often found myself storing indexes into vectors/maps and not being sure if this was a good way of doing things; it seemed better than raw pointers in some senses, but it also felt like I was just bypassing the borrow checker and using a system that had less drastic failure modes, but othewise no guarantees.
I also found myself building up datastructures of these indexes that I would not have had to do in a traditional imperative language.
I would have really appreciated some examples of writing your own data structures where a traditional encoding would run into the borrow checker (eg graphs).
I would have prefered a reference book of techniques with examples to this format, though maybe starting with a ToC of techniques would be better than a rant about linked lists.
[EDIT]: I read some more and this seems like really useful info... just not advertised or IMO presented well.
While not as complex as that, I would like to hear what you think about the slices section in the new version of the book: http://rust-lang.github.io/book/ch04-03-slices.html
It introduces slices by starting with functions that use indexes into `String`s, which sounds similar to what you were doing. It demonstrates the problems with that approach, and then shows how to use slices instead.
I'm not sure if slices would have worked well in your cases, but this chapter is so similar to what you said I wanted to point it out!
I'd say it's about on par with C++, effort-wise. Big learning curve to get something as complex as a game off the ground, and you need to think about the design, but I can't think of many long-term annoyances. The ecosystem is still sparse, so viable game projects will probably skew towards 2D and otherwise modest scale.