Author｜Harper ZhuoInterviewed｜Eric WangEdited｜Monica HeProduced｜GOSIM

"I firmly believe in the value of open source as a tremendous contribution to the world. At the same time, I understand the necessity to find a balance between open-source and proprietary software. However, what’s most frustrating is when people label projects as 'open source' when they are 'almost open source' but not fully. This trend of nearly, but not completely, open licenses distorts the true spirit of open source."

In today’s fast-paced technological wave, the Rust programming language has distinguished itself with its outstanding performance, security, and commitment to open source. As a core leader of the Rust project, Josh Triplett has spent decades deeply involved in Rust development, focusing on breakthroughs in concurrency, systems optimization, and ecosystem building. He firmly believes that Rust is its own successor, striving for continuous self-improvement.

As a forward-thinking strategist and efficient programming expert, Josh Triplett has advanced Rust through the ongoing construction of an open-source community culture, driving breakthroughs in both language features and ecosystem development. He also shared his insights on passing on the open-source spirit within the community, as well as how to cultivate the next generation of Rust programmers to become 10x engineers.

GOSIM is honored to invite Josh Triplett to share his valuable experience with tech enthusiasts around the world. During the GOSIM CHINA 2024 conference, he led a roundtable discussion titled "Fireside Chat." After the conference, GOSIM’s Open AGI Forum specially invited him for an exclusive dialogue with senior CSDN tech editor Eric Wang, diving deep into the characteristics and future development of Rust, and discussing the future path of open source.

Highlights of the Conversation:

• The legendary "10x engineer" is real. The secret to becoming a 10x engineer is to multiply the productivity of 10 other people.
• People often speculate about what language will succeed Rust. A member of my language team once said, "Rust is its own successor," especially with the continuous addition of features like the addition system. Rust strives for continuous self-improvement.
• People often have a contradictory mindset: on the one hand, they are eager to take advantage of the convenience of open source; on the other hand, they want to keep their own work secret. The middle ground for this contradiction is that most things should be open source.
• If you want to drive business development with proprietary software, then stick to it and take pride in it. If it’s not open source, don’t label it as open source.
• WebAssembly strikes a balance between portability and low-level hardware access, which aligns perfectly with Rust’s core philosophy of resolving goal conflicts.
• For us, we’ve had days of massive productivity and moments of self-doubt. We often only see the cool outcomes others share, ignoring the failures behind them. This asymmetric comparison of information can easily lead to feelings of inadequacy.

1. Open Source and Mutual Help: The Core of Achieving 10x and 100x Efficient Programmers

Eric Wang: As the former Chief Software Architect of Chrome OS at Intel, what new insights did you gain during the transition from closed source to open source?

Josh Triplett: As the former Chief Software Architect of Chrome OS at Intel, I dealt with many issues related to the differences between Chrome and Chromium. Chromium is the open-source version of Chrome, and Chromium OS is the open-source version of Chrome OS.

People often experience a contradictory mindset: on one hand, they are eager to take advantage of the benefits of open source; on the other hand, they want to keep their own work secret. While most drivers have been open-sourced, there are certain areas, like the workings of a camera, that cannot be disclosed to the public. If such information is released, competitors might copy it, thereby losing what is perceived as unique value. Additionally, different groups feel their core competitive advantage is so strong that unless they open-source their work voluntarily, others should share their source code unconditionally for their use.

The middle ground to this contradiction is that the vast majority of things should be open source. This experience made me realize that true innovation should focus on creating outstanding hardware, such as high-performance cameras, powerful processors, and high-quality laptops. If you want to stand out and have something that people are willing to pay for, you need to rely on truly advanced technology rather than keeping secrets to undermine competitors.

I greatly appreciate how open-source conditions prevent redundant work. Over the past thirty years, I've focused so much on open source because people can share their working principles and avoid reinventing the wheel. Of course, this requires appropriate compensation, as without funding and a secure working environment, no work can progress. If you're a hardware company, it makes sense to promote hardware sales through open source. However, for software companies, building a fully open-source business model is very challenging.

I firmly believe in the value of open source as a huge contribution to the world. At the same time, I understand that one must find a balance between open-source and proprietary software. What frustrates me the most is when people label something as "open source" when it is "almost open source" but not fully. This trend of licenses that are nearly but not entirely open is a distortion of the open-source spirit. If you want to drive business with proprietary software, then stick to proprietary and take pride in it. If it's not open source, don’t give it the open-source label.

Eric Wang: What is unique about the Rust community culture?

Josh Triplett: From the beginning, Rust prioritized how to treat people and how to be inclusive; this is the core spirit of Rust. We always emphasize the friendliness and inclusiveness of the community. We never claim perfection, but we promise to keep improving.

I firmly believe that Rust is always striving to stay at the forefront of this field. As a leader in the Rust space, setting an example is crucial.

As projects grow, there is always some tension between the founders' initial culture and what develops over time. Public-facing projects often tend to revert to mediocrity. More and more people approach Rust with a “just get the work done” attitude. Without deliberate effort, it can return to the average level of the software industry’s treatment of people. Any project, if it doesn’t intentionally work on maintaining and developing its culture as new members join, will lose that culture.

Eric Wang: What steps have you taken to promote building an inclusive and positive open-source community? What challenges need to be overcome in this process?

Josh Triplett: When I first encountered Rust, I was drawn to the high level of participation convenience. The Rust community has an open development process. Any changes to the language or libraries are discussed and presented in a transparent manner. This open process has brought positive impacts.

When I started getting involved, I noticed that the Rust community, from leaders to team members—including me as a new user—were sacrificing parts of their own work and priorities, spending time mentoring new users and bringing them into the community. They spent a lot of time guiding others and helping iterate, rather than just focusing on their own code.

I try to emulate this approach and pass it on to the next generation of Rust programmers. I spend more time reviewing others' proposals for Rust than focusing on my own, and I iterate on designs with other members of the Rust community. I feel this has a multiplier effect. The legendary 10x engineer is real. The secret to becoming a 10x engineer is making another 10 people’s productivity double. The only way to become 100x, 1000x, or even 10,000x more efficient is by enhancing the productivity of others. If you don't take the time to mentor new users, you’ll never be able to scale the community.

Eric Wang: As an experienced open-source contributor, do you have any advice for those who want to contribute to Rust projects?

Josh Triplett: There are some great guides online that teach people how to make their first contribution. Here, I can recommend two good approaches.

First, if there is something you are truly passionate about, prioritize it. If you're passionate about a specific area, try starting with a project that interests you but isn't business-critical. For example, I once built a tool around the Git version control system using Rust because I was interested in it, and I wanted to take the opportunity to learn Rust. When I look back at that old code now, it’s pretty awful! But we all start from somewhere, and we improve step by step.

You can also choose tasks that are within reach and doable. Some small issues that only require ten lines of code to fix can help you learn how to contribute to a project. These small contributions are important because you can't go from nothing to everything in one go.

Errors in compiler error messages are an excellent starting point. When you notice something wrong, submit a 10–15 line patch to improve the error messages. One of Rust's strengths is making the compiler as efficient as possible. Once you spot an issue, finding the best error message is a great way to start contributing.

When other programmers see the error messages you helped improve, they’ll breathe a sigh of relief, and you will have helped a lot of people. Congratulations, you've become a 10x engineer, improving the efficiency of thousands of people just a little bit.

2. How Rust Integrates Diverse Strengths and Achieves Cross-Language Fusion

Eric Wang: What challenges have you encountered while promoting the adoption of Rust by more companies, and how have you addressed these challenges?

Josh Triplett: First of all, introducing Rust into existing projects means it needs to coexist harmoniously with other technologies. When dealing with large and mature C codebases, you need to plan for gradual integration of Rust rather than a complete rewrite. I don’t want to aggressively replace other technologies with Rust; I want them to collaborate smoothly.

A viable solution is to gradually migrate portions of code from C to Rust within a C project while ensuring tests pass and users are satisfied. Maybe a few years down the road, the large project will primarily rely on Rust, but there's no rush.

Rust has excellent interoperability with C. The built-in C compiler in Rust allows you to compile both Rust and C code together. Zig has taken a different path, pursuing different levels of security, with a major highlight being seamless interoperability. Thus, better interoperability is key for Rust to integrate into existing projects and collaborate effectively, simplifying the migration process.

Another challenge lies in the contradiction between Rust's emphasis on safety, clear expression, and control, and the automatic handling of certain processes, like memory management, in languages like Python or Java. For example, languages with garbage collection handle memory automatically, whereas Rust requires manual management, such as through reference counting (ARC or RC). Rust enables the writing of highly optimized code, which minimizes memory allocations by extensively using its borrowing mechanism. Rust does not force immediate optimization of memory usage to the extreme. You can start by using cloning, ARC, and mutexes, perform performance analysis, and identify bottlenecks.

Eric Wang: In addition to C, Python, and Java, does Rust have actual connections with other emerging system programming languages, such as Go? What can Rust learn from these languages?

Josh Triplett: We strive to maintain a friendly relationship with many languages. One of the principles Rust advocates is not disparaging other languages. We sometimes make metaphorical comparisons, but we try to avoid falling into the trap of belittling other languages. Many developers use Python and Rust together, C and Rust, and even C++ and Rust. I've also seen some excellent work where Rust interfaces with C, and it's possible to make almost any language interoperable with Rust.

In the years leading up to Rust's rise, there was indeed a real language renaissance, largely driven by the LLVM compiler. The open-source and permissive licensing features of LLVM made it accessible to everyone. You only need to write a compiler frontend to leverage LLVM as a backend.

Eric Wang: You’ve done research in two seemingly different fields: the Linux kernel and WebAssembly. How has this research influenced Rust?

Josh Triplett: These experiences have given me a deep understanding of how languages run on processors and hardware, how to utilize multi-core processing or specific instruction sets, and what kind of code is generated. As a result, I can easily see the low-level details of code generation for the Linux kernel.

I’m particularly excited about the Rust for Linux project because it significantly simplifies the contribution process for Rust, making it easier to write complex drivers. I look forward to seeing how the rules that were once strict in C are now internalized into Rust’s type system. When programming in C in the kernel, your program could crash, and if you're unlucky, data could get corrupted without you even realizing it. In contrast, Rust's compiler can tell you whether your code is correct.

As for WebAssembly, the concept of portable computing is very attractive. WebAssembly is a portable layer that is fast and highly versatile, making it an ideal alternative for scripting languages like JavaScript, Python, or Lua. Embedding WebAssembly now allows programs, games, or applications to be scriptable. WebAssembly strikes a balance between portability and low-level hardware access, which aligns perfectly with Rust's core philosophy of resolving conflicting goals.

3. Challenging the Dominance of C: Rust's Successor Must Be Itself

Eric Wang: How do you view Rust’s application across different fields, such as systems programming, web development, and embedded systems? Which area holds the most potential?

Josh Triplett: Rust initially started with a strong focus on "simplifying systems programming." When the team was nearing the release of version 1.0, they made several decisions that seemed quite radical at the time but proved to be incredibly wise in hindsight. This wasn’t due to some grand blueprint, but rather a deep understanding of these complex systems. The team was working on Rust 1.0 with an emphasis on stability, but that’s not something that can be guaranteed fundamentally. In fact, some features still haven’t reached stable status today.

I’ve heard the saying that if you’re looking for languages that attempt to replace C, history is full of their remains. Through a series of decisions, Rust has not only become a language that can compete with Go or Python but also with C, which is unprecedented. This has allowed Rust to stand out in areas like firmware, operating system kernels, and web browsers. Going forward, C/C++ will also be a key area for Rust to focus on.

In the web domain, Rust also performs excellently, especially as the ideal language for writing WebAssembly. I believe Rust is moving towards becoming a general-purpose language, but there will always be certain tasks that Python or JavaScript handle better.

People often speculate about what the successor language to Rust might look like. A member of my language team once said that Rust is its own successor, particularly as features like the additive system and similar functionalities continue to be added, Rust strives for constant self-improvement. We won’t stand still or easily declare "mission accomplished"—once we do, it would signify the beginning of our decline.

Eric Wang: Looking ahead five to ten years, what do you see as the most exciting developments for the Rust language and its ecosystem?

Josh Triplett: We will gradually evolve Rust's syntax, improving the language's usability, aiming to find a better balance between clarity and automation, reducing the additional details written for cloning Arc or handling mutexes in most code, and making these operations simpler. Additionally, I expect there will be a scripting dialect similar to Rust, which would make Rust even more flexible to use.

Rust may offer a more convenient way to declare complex structures like mutex lock arcs without pushing for the extreme performance seen in C. Rust's goal is not to become a better C, but to become a better Python-like language, offering an easy-to-use REPL.

Rust will also have better interoperability with C and C++. Right now, developers use tools like Bindgen to achieve interoperability, but in the future, we may see a new model where C and Rust are used together in the same project, with clearly declared interoperability interfaces.

What I hope to see is Rust and C files being compiled with the same compiler and collaborating seamlessly, much like how C++ interoperates with C. One of C++'s most important features is its perfect compatibility with C, and I hope that Rust can reach this level as well.

4. Josh Triplett: The Open Source Leader Driven by Passion

Eric Wang: Your doctoral research focused on scalable concurrent programming. How does this field play a role in the Rust project?

Josh Triplett: My research during my PhD concentrated on building data structures that could scale seamlessly across any number of CPUs. Back then, getting access to 64-core or 128-core systems was incredibly difficult. Now, it’s possible to rent these resources in the cloud for just a few dollars an hour.

Today, with technologies like Rust, which treat concurrency as a first-class concept, and other languages, writing concurrent programs is much easier than ever before. With Rust or similar technologies, implementing concurrency features now takes minutes instead of hours or even days. Rust has made a significant contribution to simplifying concurrent programming.

Eric Wang: Can you provide some examples of how your research in scalable concurrent programming has influenced Rust’s feature design?

**Josh Triplett: **In the industry, when it comes to concurrency algorithms based on Rust, we’ve seen the adoption of RCU (Read-Copy-Update) style techniques and other related methods, like hazard pointers. Rust is an excellent example of merging cutting-edge programming language research with practical implementations that make these concepts accessible.

The academic community has long studied issues such as regional typing, memory lifecycle tracking, and ownership. Rust borrows and builds on these ideas, drawing inspiration from languages like OCaml, ML, and Haskell, while presenting them in a form that’s easier to adopt. Thanks to its design optimizations, Rust ensures that readers from non-academic backgrounds can easily get started.

I’m very happy to see so many ideas from academic research ultimately incorporated into Rust. Nowadays, many researchers have completed their PhDs or published papers based on their work with Rust, closing the loop from research to application.

Eric Wang: You’ve been working on the vision of system optimization for 16 years. How has this long-term goal influenced your personal and professional development?

Josh Triplett: There are two key aspects to this. First, people spend a tremendous amount of time building software. Turning ideas into code is the crucial moment when intellectual work transforms into a tangible product. Simply daydreaming isn’t enough—you need results to guide the next step. This is the stage where delays are most unwelcome.

We have such powerful processing capabilities, yet it should be easier to use them for compiling code. It’s difficult to convince people to spend $10,000 on high-end workstations for developers, though it would greatly boost productivity. My goal is to shorten build times, so developers have more time to brainstorm brilliant ideas, test them, and iterate quickly.

The other aspect is my dedication to the industry being able to flexibly use a variety of components to build software. Nearly every project I’ve been involved with has faced this challenge. Whether it’s combining 20 different types of resources—code, software resources, images, 3D models—or integrating code written in five different languages into a deployable software image or installation package, this is no small feat.

Enterprises have tried to build internal custom or open-source build systems to solve this problem, but there hasn’t been a true cross-language, cross-platform solution. I’m working to simplify this process, making it easier to integrate diverse components into software, and WebAssembly is my tool for binding them together as a build script.

Eric Wang: Have you ever faced a conflict between personal interests and project needs? How do you balance the two?

Josh Triplett: These two are not in conflict for me. I believe the core of open source is that developers are driven by many factors to plan and allocate their time. It’s not advisable to make decisions based solely on personal or company needs while ignoring the broader community's needs. However, using personal or company needs as a basis to prioritize one’s time and work content is reasonable.

I spend time improving Rust's build speed or exploring more efficient ways to handle concurrency. At the same time, I focus on asynchronous programming, aiming to improve the async programming experience in Rust because practical experience drawn from real projects is far more valuable than what language designers, who don’t often use their own language, can offer.

My work is really where my interests lie. This drive comes from several different places: as a consultant for Futurewei, they often ask for my suggestions on improving Rust, and I also run a company focused on build system services. This pushes me to write a lot of Rust code and contribute to the advancement of cutting-edge Rust technologies.

Eric Wang: When the AI wave hit, many programmers experienced self-doubt. How did you feel about that?

Josh Triplett: Indeed, many people face imposter syndrome, always feeling like they're not smart enough and just barely keeping up with others. A very important point to note is that we only see other people’s highlights, but we know the full extent of our own experiences. We've all had days where our productivity was sky-high, but also times when we doubted our intelligence. For others, we only see their cool outcomes but overlook the failures they might have experienced. This asymmetry of information can easily lead to feelings of inadequacy.

Actually, viewing the times we fail as a normal part of the process can be quite helpful. I like to openly share these experiences.

Regarding the impact of AI, a recent discussion on AI-assisted work efficiency found that while people feel more efficient when using AI, actual productivity hasn’t significantly increased, which aligns with many points in RLHF (Reinforcement Learning from Human Feedback). We trained AI code assistants to make people feel like they were writing code more easily and efficiently, but that doesn’t necessarily mean it improved their productivity.

Perhaps one day, AI will be able to write code that’s as high-quality and reliable as human code. But at least in the short term, I’m not overly worried about my work as a programmer, and new programmers needn’t worry too much either. AI and humans make different types of mistakes and approach problems differently. There’s still a lot more we need to worry about with AI, and what we should really focus on is aligning AI better with human needs to serve us effectively.