No Starch Press Blog Live Coder Jon Gjengset Gets into the Nitty-Gritty of Rust

Our always fascinating Author Spotlight series continues with Jon Gjengset - author of Rust for Rustaceans. In the following Q&A, we talk with him about what it means to be an intermediate programmer (and when, exactly, you become a Rustacean), how Rust "gives you the hangover first" for your code's own good, why getting over a language's learning curve sure beats reactive development, and how new users can help move the needle toward a better Rust.A former PhD student in the Parallel and Distributed Operating Systems group at MIT CSAIL, Gjengset is a senior software engineer at Amazon Web Services (AWS), with a background in distributed systems research, web development, system security, and computer networks. At Amazon, his focus is on driving adoption of Rust internally, including building out internal infrastructure as well as interacting with the Rust ecosystem and community. Outside of the 9-to-5, he conducts live coding sessions on YouTube, is working on research related to a new database engine written in Rust, and shares his open-source projects on GitHub and Twitter.No Starch Press: Congratulations on your new book! Everyone digs the title, Rust for Rustaceans - which is a tad more fitting than its original moniker, Intermediate Rust. I only bring this up because both names speak to who the book is for. Let's talk about that. What does "intermediate'' mean to you in terms of using Rust? Specifically, what gap does your book fill for those who may have finished The Rust Programming Language, and are now revving to become *real* Rustaceans?Jon Gjengset: Thank you! Yeah, I'm pretty happy with the title we went with, because as you're getting at, the term "intermediate" is not exactly well-defined. In my mind, intermediate encapsulates all of the material that you wouldn't need to know or feel comfortable digging into as a beginner to the language, but not so advanced that you'll rarely run into it when you get to writing Rust code in the wild. Or, to phrase it differently, intermediate to me is the union of all the stuff that engineers working with Rust in real situations would pick up and find continuously useful after they've read The Rust Programming Language.I also want to stress that the book is specifically not titled "The Path to Becoming a Rustacean," or anything along those lines. It's not as though you're not a real Rustacean until you've read this book, or that the knowledge the book contains is something every Rustacean knows. Quite the contrary - in my mind, you are a Rustacean from just before the first time you ask yourself whether you might be one, and it's at that point you should consider picking up this book, whenever that may be. And for most people, I would imagine that point comes somewhere around two thirds through The Rust Programming Language, assuming you're trying to actually use the language on the side. NSP: Rust has been voted "the most loved language" on Stack Overflow for six years running. That said, it's also gained a reputation for being harder to learn than other popular languages. What do you tell developers who are competent in, say, Python but hesitant to try Rust because of the perceived learning curve?JG: Rust is, without a doubt, a more difficult language to learn compared to its various siblings and cousins, especially if you're coming from a different language that's not as strict as Rust is. That said, I think it's not so much Rust that's hard to learn, as it is the principles that Rust forces you to apply to your code. If you're writing code in Python, to use your example, there are a whole host of problems the language lets you get away with not thinking about - that is, until they come back to bite you later. Whether that comes in the form of bugs due to dynamic typing, concurrency issues that only crop up during heavy load, or performance issues due to lack of careful memory management, you're doing reactive development. You build something that kind of works first, and then go round and round fixing issues as you discover them.Rust is different because it forces you to be more proactive. An apt quote from RustConf this year was that Rust "gives you the hangover first" - as a developer you're forced to make explicit decisions about your program's runtime behavior, and you're forced to ensure that fairly large classes of bugs do not exist in your program, all before the compiler will accept your source code as valid. And that's something developers need to learn, along with the associated skill of debugging at compile time as opposed to at runtime, as they do in other languages.It's that change to the development process that causes much of (though not all of) Rust's steeper learning curve. And it's a very real and non-trivial lesson to learn. I also suspect it'll be a hugely valuable lesson going forward, with the industry's increased focus on guaranteed correctness through things like formal verification, which only pushes the developer experience further in this direction. Not to mention that the lessons you pick up often translate back into other languages. When I now write code in Java, for instance, I am much more cognizant of the correctness and performance implications of that code because Rust has, in a sense, taught me how to reason better about those aspects of code. NSP: In the initial 2015 release announcement, Rust creator Graydon Hoare called it "technology from the past come to save the future from itself." More recently, Rust evangelist Carol Nichols described it as "trying to learn from the mistakes of C, and move the industry forward." To give everyone some context for these sentiments, tell us what sets Rust apart safety-wise from "past" systems languages - in particular, C and C++ - when it comes to things like memory and ownership.JG: I think Rust provides two main benefits over C and C++ in particular: ergonomics and safety. For ergonomics, Rust adopted a number of mechanisms traditionally associated with higher-level languages that make it easier to write concise, flexible, (mostly) easy-to-read, and hard-to-misuse code and interfaces - mechanisms like algebraic data types, pattern matching, fairly powerful generics, and first-class functions. These in turn make writing Rust feel less like what often comes to mind when we think about system programming - low-level code dealing just with raw pointers and bytes - and makes the language more approachable to more developers.As for safety, Rust encodes more information about the semantics of code, access, and data in the type system, which allows it to be checked for correctness at compile-time. Properties like thread safety and exclusive mutability are enforced at the type-level in Rust, and the compiler simply won't let you get them wrong. Rust's strong type system also allows APIs to be designed to be misuse-resistent through typestate programming, which is very hard to pull off in less strict languages like C.Rust's choice to have an explicit break-the-glass mechanism in the form of the unsafe keyword also makes a big difference, because it allows the majority of the language to be guaranteed-safe while also allowing low-level bits to stay within the same language. This avoids the trap of, say, performance-sensitive Python programs where you have to drop to C for low-level bits, meaning you now need to be an expert in two programming languages! Not to mention that unsafe code serves as a natural audit trail for security reviews! NSP: Along those same lines, Rust (like Go and Java) prevents programmers from introducing a variety of memory bugs into their code. This got the attention of the Internet Security Research Group, whose latest project, Prossimo, is endeavoring to replace basic internet programs written in C with memory-safe versions in Rust. Microsoft has also been very vocal about their adoption of Rust, and Google is backing a project bringing Rust to the Linux kernel underlying Android. As Rust is increasingly embraced and used for bigger and bigger projects, are there any niche or large-scale applications, or certain technology combos you're most excited about?JG: Putting aside the discussion about whether Rust prevents the same kinds of bugs in the same kinds of ways as languages like Go and Java, it's definitely true that the move to these languages represent a significant boost to memory safety. And I think Rust in particular unlocked another segment of applications that would previously have been hard to port, such as those that would struggle to operate with a language runtime or automated garbage collection.For me, some of the most exciting trajectories for Rust lie in its interoperability with other systems and languages, such as making Rust run on the web platform through WASM, providing a better performance-fallback for dynamic languages like Ruby or Python, and allowing component-by-component rewrites in established existing systems like cURL, Firefox, and Tor. The potential for adoption of Rust in the kernel is also very much up there if it might make kernel development more approachable than it currently is - kernel C programming can be very scary indeed, which means fewer contributors dare try. NSP: In the book's foreword, David Tolnay - a prolific contributor to the language, who served as your technical reviewer - says that he wants readers to "be free to think that we got something wrong in this book; that the best current guidance in here is missing something, and that you can accomplish something over the next couple years that is better than what anybody else has envisioned. That's how Rust and its ecosystem have gotten to this point." The community-driven development process he's referencing is somewhat unique to Rust and its evolution. Could you briefly explain how that works?JG: I'm very happy that David included that in his foreword, because it resonates strongly with me coming from a background in academia. The way we make progress is by constantl