For years, cyber attackers have exploited vulnerabilities stemming from a lack of “memory safety” in software. Google has made significant strides in eliminating this class of vulnerabilities, largely thanks to code written in the memory-safe programming language Rust. However, as Rust gains prominence, the maintainers behind this programming language are grappling with burnout and overwhelming workloads. The question arises: when will this bubble burst?
At Google, the term “Safe Coding” refers to a “secure by design” approach. The cornerstone of this strategy is the adoption of memory-safe programming languages. This means moving away from traditional languages like C and C++, with Rust emerging as the primary replacement. While this modernization process is time-consuming and labor-intensive, especially when it comes to kernel development, the payoff is substantial. Six years ago, lack of memory safety was responsible for 76 percent of all Android vulnerabilities; today, that figure has dropped to just 24 percent.
Google isn’t alone in this shift. Microsoft is gradually incorporating Rust into the Windows kernel to enhance memory safety. Other tech giants, from Dropbox to Amazon, have also embraced the language.
Also read: Why the Rust programming language keeps getting more popular
The U.S. Defense Department’s DARPA believes that AI can accelerate this modernization process. They’ve launched the TRACTOR (TRanslating All C TO Rust) project for this purpose. This initiative aligns with recent statements from CISA director Jen Easterly, who criticized developers for writing insecure code and its consequences. Other branches of the U.S. government, including the White House Office of the National Cyber Director, also recommend Rust for a more secure IT future.
In summary, major tech companies are adopting Rust, following recommendations from the U.S. government. As of 2024, the programming language is overwhelmingly preferred for critical software functions. However, the Rust project itself is not without its challenges.
No Rust without rest
One persistent issue among Rust maintainers is burnout. Senior engineer Jynn Nelson highlighted this problem early this year. While Rust’s complexity (in contrast to the simpler C language) is already a hurdle for many, Nelson’s blog post pointed out a problem that particularly affects experienced maintainers. Those who take on more tasks are rewarded by the community with even more work, leading to a vicious cycle. Nelson warns, “it won’t get done if i don’t do it” and “i need to review everything or stuff will slip through” is exactly the mindset of my own burnout from rust. Their advice is to provide documentation and resources for addressing burnout, just as the community does for code-related issues.
This phenomenon is not unique to Rust; it’s well-known in open-source projects. However, Rust’s growing importance means that overworked maintainers pose a real threat to the stability of numerous products. Android, Windows, and Linux already use Rust to varying degrees. And it’s not as if the language is so stable that there’s nothing to worry about. In April, the “BatBadBut” vulnerability shook the project, posing risks for Windows users. What happens if an unforeseen problem renders entire kernel components insecure? Who will fix it if the Rust community is exhausted?
Outrages
Not all departures from Rust projects are due to burnout. Feuds within the community have also caused problems. Sometimes these conflicts arise from decisions made by The Rust Foundation, such as an overzealous attempt to protect its trademark. This even led to the creation of a Rust fork called “Crab,” although this seemed primarily intended to pressure the nonprofit organization supporting the language.
The Rust for Linux project also recently experienced turmoil. Wedson Almeida Filho, who volunteered to lead this kernel project for Linux in addition to his work as a software engineer at Microsoft, recently quit. He cited “non-technical nonsense” as the last straw, stating, “After almost four years, I expected that we would be past the tantrums of respected members of the Linux kernel community. I just didn’t feel like dealing with them anymore.”
Conclusion: problems in the distance
These issues highlight not so much the dangers of open-source development as the lack of centralized direction. The Rust Foundation provides financial support for maintaining resources like crates.io, the repository for Rust’s equivalent of libraries or packages. However, the Rust project is far more informal and decentralized, and not driven by The Rust Foundation. Unlike projects such as Android (backed by Google) or Kubernetes (supported by the Cloud Native Computing Foundation), there isn’t a single entity keeping things aligned.
It’s expected that Rust (or a fork of it) will eventually undergo further evolution. This is because even after years of transitioning from C to Rust, vulnerabilities will still remain, and it will become clear that not every problem can be solved overnight by increasingly overworked volunteers. The question is who will take on that task, and whether, as now, it will be done on a volunteer basis.
As Rust continues to gain prominence in critical software systems, addressing these internal challenges will be crucial for ensuring its long-term stability and success.
Also read: The Julia programming language: a missed opportunity for AI