Carol & Chris chat about The Rust Book (3rd edition)

What's your favorite crate name? Butt plug. Butt plug is — I've had the immense privilege of sitting down with Carol and Christie, co-authors of The Rust Programming Language, 3rd Edition, which now has async await. And we have talked about everything from writing the book to editing the book to deciding what should and shouldn't be in the book to conflict resolution between co-authors, and most importantly, what they would do if they had to do the book over from scratch again. I would not. I simply would not. Never mind that one. I think all we have to do is say, "Hi, Vivian. " and learn how the book is made. The history of the Rust book is complicated and long. It dates back to when Steve started writing Rust for Rubyists back in like 2014. The main piece of work this time around was go triage all of the open issues on the project and then go write this chapter on async await. Async await showed up in the ecosystems as a stable feature of the language in 2019, and we were working on this in 2024. So, we'd had 5 years of the book existing with zero coverage of async await in it. And weirdly, because of the corners and turns my career had taken, I stopped teaching Rust stuff through the podcast 3 months before async await stabilized, and I hadn't had time to go back and pick it up. So, I taught myself async Rust and then fed what I learned in the experience of doing that into how do we cover this in the book. And that ended up actually working out really well, I think. I mean, obviously, I had Carol giving input, but we also found a bunch of folks in the community willing to come give reviews. James Munns, Jon Gjengset Turner hugely helpful. Tim McNamara did a pass. We did a really big reorg after Sophia took a pass. But it's still like a 20,000 word chapter, which is actually just a short book. And there is a whole separate async book that NRC is the main contributor of. But yeah, I was super grateful for Chris to have the availability he did come in and help. — And then I got back into the normal full-time job world and suddenly had no more time anymore, and Carol was able to pick it up and carry it through the next phase. The next part is like sending it to No Starch, our publishers. We have a cobbled-together spaghetti of weird scripts and Rust programs and a little bit of XSL in there because we did our first draft in Markdown. We do a couple rounds of editing in that. At some point, No Starch moves it to a Word doc, which is essentially an XML document. So, I want it back into Markdown to be able to do the diff and get the changes back into the online version. So, you have bidirectional sync. Oh, that's terrible. It's so hard. Yeah. Oh, it's so terrible. And then there's like the built version of the book because we have a lot of error messages that we show in the book. So, when the error messages change, we need to update those. So, I have a script that will go through compile all the examples, save the output, build the book with the new output, compare it to the old book's output so I can see like when the error messages change and see if we need to update the text around the error messages. Then after the Word version eventually gets into PDF like InDesign, Chris and I are not allowed to touch it at that point. We have to leave comments, and their designers have to move things around. Then like I don't have a way to backport things from there. But usually it's kind of visual changes that we don't really need. So, it's not as much of an agile style — Publishing in general is not. waterfall No, which does kind of clash with like the open-sourceness of the book cuz people are like, "Oh, this sentence was a little bit confusing. It'd be it would be better if this" I'm like, "Do you know how many rounds of edit of like edits I have to do if I merge this? It this is not that big of a deal. " I think it was great. I like that they don't shy away from whimsy. That's in the whole branding, right? If you go to their the website and everything, all the little drawings. And the text of the book, for better or for worse, is licensed MIT, and they are fine with that. So, we're able to offer the free web version, which is also great. The editors that we've worked with have been super helpful and have greatly improved the book. And it looks very pretty. I love their typefaces and the way their books are laid out. So, yeah, I'm really glad they're involved. Very little to say other than that. They're pros, and they're great, and I really enjoyed working with them, and I don't know if I'll ever do a programming book again because it's really hard, but if I did, I would be very happy working with No Starch. I would be interested to know who has read the book cover to cover cuz it's a lot. Whenever anyone is like, "Why don't you cover this in the book? " we keep we cannot fit anything any big more big topics in this book. There needs to be more books. If you're listening this and you're well, I don't know if I wanted to help —

— cuz it's kind of terrible, but it doesn't have to be a whole book. It can be, you know, a blog post or a YouTube video. Write up what you learned from your perspective because we need lots of different points of view to help everyone get in, and the book can't possibly be all of them. We need more. I mean, my background was weird. I wrote a weird mix of Fortran and C and C++ and PHP. That made my experience of learning very different from someone who came in through purely the Ruby on Rails world or came in through purely a JS boot camp. So, what is the difference and what do I do to bridge that? Those are the kinds of questions I start trying to ask when I hit those. Yeah, the worst is when you're using the same words and not until way later you realize that you have different meanings for those words. Yeah, and we actually made a point with async await to call that out, that these are words that you're going to be used and the concepts are similar to what you'll be familiar with, but there are some really important differences, and we try to flag them up like the fact that futures are lazy. That is not JavaScript's approach. And that makes a really big difference in your mental model for it. Will Crichton is a professor at Brown. He's done some research. He has actually an alternative version of the online book with some exercises built in. His theory is that you could actually push learning about ownership way later, and that people drop out when they learn about ownership. But our early intuition was, "Okay, ownership is the most different thing about Rust. So, we should hit you with that early. You're always going to run into these ownership errors, and you're going to need to know about it. " I think I would love to hear your opinion. I think you got it right. I think you're right. I think it's the most different thing. When I hit that chapter, I was like, "I'm going to keep hitting that wall until it breaks. " And it took a couple tries, but it did. And now I know the real model, and I think it's kind of bait and switch to just say, "Yeah, you can arc clone all the things. Don't worry about it. " and then later on you're like, "Ah, okay, this whole static analysis thing that like literally no other language is doing. I'm kind of on the other side of the argument here. Like if you are being asked to use Rust at your job and you don't actually want to and you're trying to just do your job, like maybe pushing off ownership would be would help you get started faster. For anyone who hit the Chapter 4 ownership and dropped out, go read the Brown version if you feel like you're getting stuck with ownership and maybe put it off till later. — You could argue that there's like two different levels of Rust that you can write, and one is borrow as much as you can, don't clone. And then a higher level, which is what you find if you're trying to write a web server on top of Axum and everything is boxed and everything is like don't have to worry about lifetime so much until you can have like the senior Rust expert engineers work on the lower level. But the thing is that the people working on the upper level of Rust are not really happy because it kind of sucks to have to wrap everything in arc and then you get concurrency bugs because of that. depends on your context a lot. And there have been people who have thought about making a variant of Rust that like everything is just arc by default and you don't have to arc clone everything. I don't know if any of those have progressed to a useful state yet. I think we would know. I think between the three of us, we would know. Not. But I mean, Swift also has really good prior art in that Swift does use basically compile-time reference counting as the default mode. And the performance is not quite where Rust is, but it's very good for a lot of things. I love Rust. But what I'm actually almost more excited for in some sense is, "Okay, 20 years down the line, what do we get that learns the lessons from these things and says, 'How do we make all the things that we learned from making borrowing easier and ownership easier and all the things that Swift and experimental languages like Val and Hylo and stuff like that are doing with value semantics? '" Like that's going to be really interesting because this area is really hard. I'm also excited to see what comes after Rust. I don't think Rust is the best programming language ever. I think it's a big step forward. — It is a major achievement. Like I feel like I now command some respect as being the author of The Rust Programming Language. And sometimes I kind of stop and think about the good comments we get. They really enjoyed the tone and so I feel like I have impacted the world by doing this, which that is what I want out of my [clears throat] career. And so, I run my own consulting company, Inner Drive 32, with my husband. I think we have gotten some leads that have said, "Carol wrote the book. " So, yeah, I think overall it was a good career move for me. I also think I was super lucky. Rust took off. You know, I happened to be in the right place at the right time to help out with the book, and I know a lot of other tech books don't do as well. For the record, there is absolutely no question that yes, you've had a huge impact on a huge number of people in a very positive way.

— I don't think it's all that bad. I feel like we're both well aware that there are trade-offs in everything. The stuff we produce together is not a reflection on either of us as a person. Especially as an author, I think there's a degree to which you have to know that you're too close to it because you're the one who wrote the words. When I have three people I really respect come back to me and tell me that it's not working, I should probably listen. And also in this case, a thing I was very conscious of is this is not written in my authorial voice. You're always doing the work of trying to say, "Look, I'm adding to a thing that already exists and I'm going therefore to try very hard to make this fit with that. " I came in respecting the work that already existed and respecting Carol as an author. It was a pleasure working with you, Chris. I'm really glad this ended up Likewise. You can get your own copy of this book for 40% off using code TRPL40, that is purple 40. It's in description if you can't spell. That's all for me today and remember, only a bad teacher blames their students. — Take care. I'll see you next time.