A profound look at the intellectual craftsmanship required to bridge low-level systems complexity with accessible pedagogy. This conversation underscores why the Rust Book remains the definitive blueprint for modern technical documentation.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
Carol & Chris chat about The Rust Book (3rd edition)Added:
What's your favorite crate name?
carol: buttplug.
amos: buttplug is your favorite crate name? carol, insistent: butt. plug.
amos: I've had the immense privilege of sitting down with Carol and Chris, the 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 five 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 three 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 Sophia 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 to come in and help.
And then I got it 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 the worst.
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 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.
And 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.
Which does kind of clash with like the open source-ness of the book because people are like, oh, this sentence was a little bit confusing.
It would be better if this, I'm like, do you know how many rounds of edits I have to do if I merge this?
This is not that big a deal.
I think it was great.
I like that they don't shy away from whimsy.
That's in the whole branding right there.
If you're on the website, you're doing all the little drawings.
And the text of the book, for better or for worse, is licensed to 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 because it's a lot.
Whenever anyone is like, why don't you cover this in the book?
We cannot fit anything, any 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 want to tell people to read it because it's kind of terrible, but it doesn't have to be a whole book.
It can be 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 bootcamp.
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 use 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 our early intuition was, OK, 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 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 of 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, OK, 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.
I don't even want to hit the chapter for ownership and dropped out.
Go read the brown version if 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 lifetimes so much.
And so you can have like the senior Rust expert engineers work on the 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 Mutex and you get concurrency bugs because of that.
It definitely 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 clone everything.
I don't know if any of those have progressed to a usable state yet.
I think we would know.
I think they're mostly fair.
I think between the three of us, we would know.
Yeah, this is 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.
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 enjoy the tone.
And so I feel like I have impacted the world by doing this, which that is what I want out of my career.
And so I run my own consulting company, integer 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.
I happen 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 that bad.
I feel like we are both well aware that there are trade-offs and 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, the 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, likewise.
You can get your own copy of this book for 40% off using code TRPL40.
That is purple40.
It's in description if you can't spell.
That's all from me today and remember, only a bad teacher blames their students.
Take care.
I'll see you next time.
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
🚀 BCS613C Compiler Design | Module 1 to 5 Schema Evaluation 🔥 | VTU 6th Sem 💯 #VTU #bcs613c #exam
Pranavaa-y4y
104 views•2026-06-02











