Rust in Linux: A Powerful Tool—But How Do We Strike the Right Balance?

\ The heated debate about including Rust in the Linux kernel has been ongoing for quite some time in the hacker community. Most of us recognize both the hype and the hesitations about it. So far, most of the discussions have focused on immediate issues, such as Rust’s security benefits and the challenges of integrating it into the existing C-based ecosystem. Now that Linus Torvalds is on board with this idea, Rust has already started making its way into the source code of our beloved operating system.

\ Thus, the real question isn’t whether to use Rust in the Linux kernel, but how. After all, Rust isn’t just another programming language; it is also a fully-fledged design philosophy. It is not an upgrade of C with fewer memory corruption bugs, but a system of writing code that forces a strict ruleset, thereby preventing many potential mistakes. I believe that this is the key aspect we need to be mindful of when embedding Rust into the Linux kernel.

\

According to research on organizational ambidexterity, very large-scale projects like Linux must continuously engage in two types of activities to stay adaptable, relevant, and successful:

1. Exploitation: Efficiency, refinement, and execution. In Linux, this refers to activities such as optimizing features, fixing bugs, and addressing concerns of existing users.
2. Exploration: Experimentation, risk-taking, and innovation. These activities allow projects like Linux to develop novel approaches, adapt to disruptive technologies, and meet changing user expectations.

\ Research also shows that short-term-oriented exploitation activities tend to drive out long-term-oriented exploration activities. This is like wanting to learn a new skill or work on an unconventional project but always prioritizing daily tasks instead. The same applies to large projects like Linux; if they focus too much on short-term efficiency, they risk becoming obsolete in the long-term. The world keeps changing while the project stays the same, making its offerings increasingly irrelevant to the evolving user needs.

\

On the one hand, adopting Rust is a very unconventional experiment that can be considered as an exploration activity for Linux. From this perspective, Rust’s inclusion is well-founded. However, on the other hand, unlike C—which embraces all kinds of craziness and undefined behavior with open arms, making it the go-to language for low-level hacking—Rust has an internal bureaucracy that enforces a certain structured way of writing code. In a sense, Rust functions as both a programming language and a process management system, similar to methodologies like Six Sigma. A specific, structured way of writing code can certainly help streamline processes and improve short-term outcomes, such as security vulnerabilities and reliability issues. However, just like in the cases of other process management systems, this rigidity also introduces risks to long-term agility and adaptability.

\ Therefore, Rust’s merits in streamlining processes and making them safer would shine particularly in kernel components where long-term adaptability is less critical. For example, device drivers interact directly with external inputs and are high-risk components in terms of memory safety and reliability. Thus, it makes sense to write them with Rust. They also tend to have relatively shorter lifespans, as new devices frequently replace old ones. In other words, the concern that Rust methodology might decrease exploration, or the possibility that eventually we might want to move away from Rust due to changes in code writing philosophies becomes less relevant. When a device driver is developed with Rust, it is typically safer and more reliable, and other components are not built on this code. As a result, it does not force anyone to a particular way of writing code in a few decades.

\ In contrast, core components of the kernel, such as the scheduler, need to remain adaptable to accommodate future challenges and novel paradigms. Using Rust in these areas could introduce rigidities that hinder exploration and lead to obsolescence. Think of it this way: Future code needs to build on the components being built today, and when eventually a different philosophy of writing software proves to be more advantageous in the future, the highly flexible C code can generally be changed incrementally until it is transformed into the new approach (incremental strategic renewal). In contrast, Rust insists on its own way of writing code, so this is likely to cause a dilemma of continuing to develop with the old approach versus writing it from scratch. Considering that free software has always had difficulties in finding a sufficient number of qualified and regular volunteers as well as a sufficient amount of regular funding, incremental improvement is always much easier than deciding to undertake a major project like throwing away a component and writing from scratch. Therefore, any language that insists on a particular way of writing code can become a liability in the future, forcing Linux to continue with an older way of writing code and losing its cutting-edge position.

\ In brief, I propose a hybrid strategy in which Rust is used more for short-term components where security is crucial, while C—the most agile language that is not specific to hardware—is prioritized for long-term components to maintain flexibility for future paradigms and approaches.