Hacker News new | comments | show | ask | jobs | submit login
What’s New with “The Rust Programming Language”? (steveklabnik.com)
143 points by doppp on Aug 15, 2016 | hide | past | web | favorite | 50 comments

I really like Rust. As someone who never had a formal computer science education, the early version of this book helped me understand how programs handled memory in a way that no other resource has been able to.

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 am really glad to hear it. One of the reasons I had made the Ruby -> Rust jump fairly easily was that I'd been programming in C for most of my life, and got a BS in CS. But I also know that a _ton_ of people have not. So it's really really important to both me and the Rust team broadly that we make Rust accessible to this crowd.

(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. )

I have a serious question: Is anybody using Rust in production? I mean, I have seen so many countless blogs about it, but I have yet to hear it being used seriously.

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.

FWIW, I'm using it for https://imageoptim.com/api — it's an image compression API. Rust is at its very core (with high-level fluff in NodeJS). It's not large scale yet, but that's only because I'm just starting.

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.

Why don't you like Cargo? Do you use pure Rust or have FFIs to C libs?

Wired has an article describing how Dropbox switched over to Rust as they moved away from AWS:


It takes time to build things.

> At this point it looks like it is just a lot noise/marketing but no real large scale deployments yet and why is this?

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?

We've seen success with people using it as part of a stack, rather than a new product. For example, Coursera, which didn't change their product, but integrated Rust into their deployment structure. Or Skylight, which re-wrote a Ruby gem from Ruby into Rust, without changing anything else about the rest of their product.

From what I can tell, there are plenty of production uses that are specialized enough to not really be shareable. There aren't any killer frameworks to attract the same attention products from other languages might get.


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?

This is a great question, with a lot of details. So, let's start from the beginning.

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/
etc. Since the current book is stored in-tree, this is just part of the regular release cycle. That said, I haven't been working on the book because I've been working on the new book, so it's largely the same, just with some typos.

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?

Related: I understand the versions hosted at doc.rust-lang.org you mention above, but what's about the version linked in your post? ( http://rust-lang.github.io/book/ ). It's what's in master right now, right?

EDIT ah, https://github.com/rust-lang/book clarifies this, it's a rewrite, and is not (yet) part of the main Rust repository.

The version hosted on docs.rust-lang.org is the current edition of the book, whose source is in-tree. https://github.com/rust-lang/rust/tree/master/src/doc/book

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.

> 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.

Makes perfect sense, and my apologies for not having found that sooner. I'd only ever looked at the main book link found in your post, and missed a bunch of valuable resources.

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.

Clearly I'm not Steve, and can't speak to his or the teams goals with the content of the book, but you can find the complete source for the book in the Rust repo[0]. Feel free to send some pulls with the content you'd like to see!

[0] https://github.com/rust-lang/rust/tree/master/src/doc/book

It's really the same as any open source project, just with words instead of code.

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.

Hi all! As always, happy to answer questions here.

The Rust Programming Language remains as one of the best introductions I've had to a new programming language. I thank you for your work on it.

Yes, and the work on the documentation in general. It's amazing. So many other young languages are crap in this area, even mature ones. I think the thing that makes Rust amazing is that it's young, and yet well documented, making it easier to get started.

Can't thank you enough, nice work.

Thank you so much. :)

Just a quick comment, there's no date on the post, at least when viewing it via mobile. It's kinda important when you're reading an article with the title "what's new ... ". :)

Thanks! This is Svbtle, so I can't control that, but it's right above the title; though it's a light-gray until you hover.

August 15, 2016, for posterity's sake. :)

Okay just noticed it :) Thanks!

It does this weird thing on desktop where the date is barely visible above the title until you mouse over it. Not sure why.

I don't understand why so many blog platforms choose to hide or obscure the timestamp of the post. It's like they don't consider whether something is current as relevant, like every since post they contain is some timeless pearl of wisdom meant to withstand the test of time and be just as useful a few years down the road.

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.

It's been about a year since I wrote any Rust, but one of the things I struggled with is having an intuition for the "right way" of dealing with the borrow checker.

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 agree with Steve that you'll probably love the "Learning Rust With Entirely Too Many Linked Lists" that he linked to.

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 liked the slices section. (And I personally found it more direct and more useful than the linked list post.)

Awesome!!! Glad to hear it :)

Thanks, totally hear that. We should promote http://cglab.ca/~abeinges/blah/too-many-lists/book/ more...

I had a brief glance at this and while this seems to present a continuous story, I had to read all the way to section 2.4 to learn anything new (mem::replace) without any idea of whether I would.

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.

Yes! This document was instrumental for me in getting my foot in the door of understanding how to use memory in Rust.

At a glance, the new material looks excellent, especially liking the illustrations in the Ownership chapter!

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.

Thank you, I spent a bunch of time fighting graphviz to make them.

Slightly off topic, but the previous blog post's embedded tweet isn't centered like it seems like it was meant to be. Just caught me off guard and figured I should mention it.

Thanks, I'll check it out. Dunno what's up. Gah!

Read through the Rust book and really enjoyed it. Curious when you think the next rewrite will be done.

I am trying to shoot for roughly the end of the year.

Has anyone used Rust for game development? I know about the Piston engine but has anyone successfully released a commercial game on Windows, Mac OS X and Linux with it or is it still pretty much an academic endeavour to make games in Rust?

I've been developing a hobby game engine and did a 7-day roguelike with it last year: https://github.com/rsaarelm/phage

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.

There's Shar Bringer, which is still in progress but is looking like it's gotten way past academic: https://www.reddit.com/r/rust_gamedev/comments/4qlftu/look_o...

One feature request - could the book be made available in info format so that its idiomatically integrated into emacs?

Is there a good markdown -> info converter? I don't use emacs.

The default answer for "is there a X to Y?" converter for text formats is pandoc, so one could possibly go markdown -(pandoc)-> texinfo -(makeinfo)-> info. I do not know if this is sufficiently high fidelity.

Will give this pipeline a shot and see what the results look like.

OT/typo: "and I’m proud to have her name next time mine on the cover" should have -time and +to. Keep up the good work!

Gah, thanks!

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact