Jim Blandy: Before Rust’s Birth, I Thought C Had Reached the Pinnacle of System Programming Languages

Author｜Monica HeInterview｜Eric WangProduced｜GOSIM

In the fierce competition of programming languages, Rust has rapidly risen to prominence with its outstanding safety, high performance, and modern syntax, becoming a shining star in the field of system programming. Its success has not only changed people's traditional perceptions of system programming languages but has also sparked new reflections on programming language design across the industry. Behind this success lies the contribution of open-source pioneers like Jim Blandy.

Jim Blandy, the author of Programming Rust, has been involved in open-source projects since 1990. After graduating from university, he worked with Richard Stallman, a pioneer of the free software movement, and became a core maintainer of the GNU debugger and Emacs, as well as one of the initial designers of the Subversion project.

When Rust was born, Jim had been a close friend of its original designer, Graydon Hoare, for many years. Before that, Jim had always believed that C and C++ had reached the pinnacle of system programming languages, with no further breakthroughs possible. However, the emergence of Rust completely overturned his perception. He never imagined that after giving up the flexibility of pointer manipulation, a language could still be so efficient and easy to use. He immediately realized that he had to write a book about Rust to document this great innovation.

Jim Blandy has personally witnessed the rise and transformation of open-source software. He believes that the greatest achievement of the free software movement is that developers now take the use of free tools for granted, no longer accepting the limitations of proprietary software. With his deep insights into programming languages and his unwavering dedication to free software, Jim Blandy engaged in an in-depth conversation with Eric Wang, a senior tech editor at CSDN. In this exclusive interview, he shared his profound understanding of Rust, his firm belief in the free software movement, and his outlook on the future of open-source software.

Highlights of the Conversation:

• Some people think the free software movement is dead, but I completely disagree. In my view, the greatest achievement of the free software movement is that developers now take for granted that the tools they use should be free.
• I once thought that C and C++ had reached the limits of system programming languages and that there couldn’t be any further breakthroughs. I never imagined that, after giving up the flexibility of pointer manipulation, a language could still be so efficient and easy to use. I immediately realized that we must write a book about it to document this great innovation.
• I believe that VS Code has indeed taken up the mantle of Emacs and become the inheritor of the Emacs spirit.
• A core limitation of Rust is that it does not allow both shared and mutability at the same time.
• He concluded, “When Rust’s borrow checker smells smoke, there’s definitely fire,” which made him realize that the flexibility in C language might not always be a good thing. Rust’s strictness can actually help developers avoid mistakes.
• I do think Emacs is a bit outdated, though of course, I might be outdated myself. I’ll keep using Emacs until my last day.

1. Open-Source Pioneer: Documenting the Birth of Rust

Eric Wang: Could you tell us about yourself and the book Programming Rust?

Jim Blandy: I've been involved in free and open-source projects since 1990. After graduating from university, I worked with Richard Stallman, and later started working on GDB, becoming one of the core maintainers of the GNU debugger and Emacs. I was also one of the initial designers of the Subversion project, although Subversion has gradually become outdated. I still remember the first time I used Mercurial. Compared to the version control systems we had been using, Mercurial represented a significant leap in performance, excelling in all the aspects we cared about. So, I decided to move from Subversion to Mercurial.

Since 2008, I've been working at Mozilla, involved in various parts of the browser development, including the JavaScript engine, debugger, developer tools, and the current RDP implementation. During this time, I collaborated with Jason Orndorff to co-write a book.

When Rust was born, I was friends with its original designer, Graydon Hoare. We had worked together at Red Hat, and later, he joined Mozilla and invited me to join him. He told me he was designing a new programming language—Rust, and I was very interested, eager to try it out. At the time, Rust was still a very unique language. Graydon was more focused on making some performance compromises for better semantic design. Today, Rust has developed into a strict and efficient system programming language, producing code of exceptional quality, and it competes with C++ without any disadvantage.

This wasn't Graydon’s original vision, but the release of Rust 1.0 made us all very excited. The problem that Graydon cared most about—safety—was solved by Rust, making it a truly safe system programming language. This was shocking to me because I had thought that C and C++ had reached the limits of system programming languages, with no breakthroughs possible. But the emergence of Rust shattered that perception.

Rust, through its unique strict memory management model, gained safety advantages over C and C++. But this came at a cost—you have to give up some flexibility. To gain the safety and reliability Rust offers, you must sacrifice some expressiveness. I never imagined that after giving up the flexibility of pointer manipulation, there could be a language as efficient and easy to use as Rust. So, when I saw these features of Rust, I immediately realized that we had to write a book about it to document this great innovation.

Eric Wang: How did the second edition of the book come about? How long did it take to write?

Jim Blandy: Writing the second edition wasn’t easy for me. Some might think writing is a straightforward task, but for me, it’s always full of challenges. I always worry that despite my best efforts, the result might not be ideal. Writing is actually a process of discovering gaps in my understanding—when you try to put ideas into words, you often realize you don't fully understand certain things.

This process can be quite frustrating, especially when facing a tight deadline. It feels like, "Wait, maybe I don’t actually know what I’m talking about!" In such situations, I had to pause writing, conduct some experiments, and write some interesting programs to really grasp the concepts before continuing. Only then could I have the confidence to write it out. The pressure of writing was considerable, and this is one reason the second edition took quite a while.

The first edition was written by me and Jason together, but the second edition was just Nora and me. For the third edition, I’ve invited all the original authors to return, hoping that we can help, inspire, and encourage each other. This collaborative approach is meaningful and has made us excited for the third edition.

Eric Wang: Will graphical programming be included in the third edition?

**Jim Blandy: **We're currently working on the third edition of the book, and O'Reilly hopes to release it in 2025. We are revising it for the 25th edition of Rust. When working on the next edition of the book, we realized that choosing appropriate examples is one of the most challenging parts of the writing process.

A key feature of the book is that when explaining language concepts through examples, the examples themselves must not be overly complex or distract the reader’s attention. Otherwise, the reader may struggle to understand what the example is doing, let alone use it to understand Rust’s true application. Graphical programming is full of strange and unexpected details, so it becomes very difficult to find content that is both educational and doesn’t distract from the main point.

In my view, graphical content hasn’t yet achieved the goal of being both educational and engaging enough to teach Rust language concepts effectively. I’d love to combine them, but the focus of the book will always be on teaching. Some might say this is just documentation, but I must clarify—it’s not documentation. It’s an explanation. The book aims to educate readers and lay the foundation for them to understand documentation, providing basic concepts, frameworks, and motivation. So, we must stay focused on teaching.

Eric Wang: In the book, you compare Rust to C and C++. How has Rust changed your view of system programming languages?

Jim Blandy: Before Rust appeared, I thought there wasn’t much room for improvement in the field of system programming. The core task of system programmers is to control machine resources. They need to be able to predict the behavior of generated code and understand how data is represented in memory. This need for low-level control made the design of C language seem inevitable. However, C can be difficult to use, especially in large-scale projects.

Then came C++, which tried to address C’s shortcomings by introducing features like generics. But I thought there wasn’t much more room for better language design. However, the emergence of Rust changed my view. It made me realize that in language design, we actually have many options, and what’s unique about Rust is that it offers a solution that’s both safe and practical.

In fact, designing a safe language is not that difficult, but the real challenge is designing a language that is both safe and practical, and Rust has achieved that. What impressed me was that Rust’s safety features are actually a unique subset, but they almost cover everything needed for system programming.

I have a brilliant programmer friend who was one of the original authors of GNU Grep. When GNU Grep was released, the entire Unix community was thrilled because it was much faster than other similar tools. When Rust first appeared, he said he wouldn’t use Rust because he often worked with graphs, and Rust doesn’t allow creating cyclic references. He couldn’t accept this limitation of Rust. I understood him. However, when I started working with WGPU, I found that Rust’s limitations weren’t a problem. Rust provided excellent performance while staying true to its development model. This made me realize that Rust’s limitations are actually an advantage. They help developers avoid potential mistakes.

One of Rust’s core limitations is that it doesn’t allow simultaneous shared mutability. If you have data accessed by multiple threads, that data must be immutable; if you need to modify the data, you must ensure no other thread has access to it. This limitation is a bit strict, but it’s exactly what makes Rust unique.

My co-author Jason Norendorf likes to rewrite simple C programs in Rust as a hobby. He finds that, most of the time, the conversion goes smoothly, but occasionally he encounters code that can’t be directly translated. He realizes that these instances in C code often contain potential bugs. He concluded, "When Rust’s borrow checker smells smoke, there’s definitely fire." This made me realize that the flexibility in C language might not always be a good thing. Rust’s strictness actually helps developers avoid mistakes. This made me wonder if we’re really making the most of that extra freedom. In fact, the frequency with which C++ programs are written correctly might be much lower than we think. In the end, time will prove everything.

2. The Free Software Movement Never Died

Eric Wang: As a developer who has dedicated your entire career to the free software movement, what do you think have been the greatest achievements and challenges of this movement over the years?

Jim Blandy: I've become more optimistic. Some of my friends believe the free software movement has died, but I completely disagree. In my view, the greatest achievement of the free software movement is that developers now take for granted that the tools they use should be free. However, when we first started, this was not a universal expectation. At the time, software was viewed as a business—if you used certain software, you had to pay for it, and developers had to restrict users' freedom to ensure they paid. Of course, here "free" refers to freedom, not price. That's what I want to emphasize.

In the past, people thought they had to accept the proprietary software model, but this mindset has now changed. GitHub is a great example. Its core mission is to promote open-source software by providing the basic tools and resources for open-source projects. While GitHub itself is not open-source, it has provided enormous support for many interesting works. To me, the most significant change is how people now view their own needs. People now believe they have the right to access source code, use free tools, submit bug reports, and participate in the development process. If things don't go the way they want, they even have the right to "tear it apart." These beliefs are deeply ingrained in the entire industry, and we can’t escape them.

Those who are pessimistic about open source tend to focus on projects like the Linux kernel. The Linux kernel is undoubtedly a huge success in the open-source domain. As more people adopt it, its use becomes more widespread, and its position in the tech market becomes stronger. For Google, Linux is critical; for Microsoft, Linux is equally important. Microsoft’s attitude toward open source has undergone a dramatic change over the past decade, mainly because they realized that they make more money through Azure than through Windows. Users of Azure want to run Linux on it, so Microsoft realized that being friendly to Linux was in its best interest.

Today, some large companies are making huge profits in the Linux kernel domain. In this context, it is indeed difficult to adhere strictly to open-source principles. For example, there have been cases where people have distributed the Linux kernel without providing source code, which is a clear violation of the GPL, and enforcing this is very challenging. So, I understand why my pessimistic friends are concerned, but I think the fact that everyone now believes development tools should be open-source, and that more and more open-source projects are being released, is a truly wonderful thing.

3. VS Code as the Spiritual Successor to Emacs

Eric Wang: As a former maintainer of GNU and Emacs, how do you view the role of classic software like Emacs?

Jim Blandy: Emacs still holds a special place in my heart in modern programming environments. My first encounter with Emacs was back in 1986, which was a long time ago. What made Emacs so charming was that every time you launched it, there were always unexpected, magical, and practical features that appeared. This might sound silly, but the ability to hit the Tab key and get the correct indentation was incredible at the time.

Today, that seems like a given, but back then, it was astonishing that Emacs could do that. Even more impressive was how, when you opened a Perl script, Emacs already understood Perl—knowing how to indent the code and even offering full command support for Perl. This reflects the strength of the Emacs community—whatever you wanted to do with it, someone had already put in the effort to make it possible. Emacs has been around for a long time, simplifying so many things, and that’s part of its charm.

So, where is that energy now? Obviously, the focus has shifted to Visual Studio Code (VS Code). In VS Code, you can find all kinds of quirky plugins, which is exactly what I loved about Emacs back in the day. That’s why I think VS Code has truly taken up the mantle from Emacs and has become its spiritual successor.

I have a friend who wrote a plugin for VS Code, and when you type really fast, the text on the screen catches fire and plays guitar music. It sounds silly, but it's really fun. He even forgot he installed the plugin, and one time, as he typed fast, the text caught fire and started playing guitar music. That brought me back to the days of Emacs. So, I think this energy has found a new home, and that’s a good thing.

But I also feel that Emacs is a bit outdated now. Of course, maybe I am too. I still use Emacs because it has become second nature to me, it’s instinctual. Fortunately, Emacs continues to improve. For example, tools like Magic for Git and the org mode, along with pretty good language server support, still surprise me. Emacs is keeping up with the times. I’ll keep using Emacs until my last day.

4. Empathy for Users is Crucial for Open Source Maintainers

Eric Wang: As an experienced programmer and project maintainer, what do you think are the key skills or qualities required to be a good programmer and maintainer?

**Jim Blandy: **I don’t really think of myself as an excellent programmer. I believe the most important thing a maintainer can do is to have empathy for the users. I know some very talented people who, when solving problems, try every tool they know. Their solutions might include macros and features.

Think about what it's like for a user with less reading ability to understand what you’ve written. The easiest thing for them to understand is what they expect to see—don’t use more complex language than necessary. I think that’s the most important advice I can give as a maintainer.

As a maintainer, one of my weaknesses is probably in social interactions. For example, reviewing things quickly is really important. It’s bad if you don’t review contributions to your project in a timely manner. I’m slow at reviewing, but fortunately, someone in my team is very good at that. Successful projects often have diverse teams, where every member has their own interests and expertise, and effectively integrates those diverse skills and resources to cover all the necessary aspects of the project. That might be the real secret.

Eric Wang: You previously suggested that open-source practices are the best way to develop tools for programmers. Do you think the study of OpenStreetMap could be applied to other areas like music or map creation?

Jim Blandy: I’m reconsidering whether to continue with that research. The existence of OpenStreetMap makes me feel it may no longer be necessary. OpenStreetMap is an outstanding project and a successful open-source case. However, in music, it’s different. I think people’s love for music stems more from an emotional connection with the creator. People want to resonate with the creator and feel their emotions. Music is more of a personal expression, rather than a collective collaboration.

In fields where the creator’s identity is crucial, like music, the open-source model might not apply. But in software, people care more about whether the software is useful, not who wrote the code. The essence of open-source is collaboration and collective effort, much like Wikipedia. No one says, “I am the author of this Wikipedia article.” Because Wikipedia articles don’t have a single author—everyone is the author. Open-source projects are the same. You can say, “I started this project,” but over time, the code evolves, and the final result is no longer owned by a single person.