Rust was not born to win a cultural war among programmers. It was born to solve a very specific problem: writing low-level software with the performance of C and C++, but without a large share of their memory errors. Almost two decades after Graydon Hoare began working on the language as a personal project in the Mozilla orbit, Rust has become one of the industry’s most serious bets for reducing vulnerabilities in critical systems.
Its story has all the elements of a strong technology narrative: an almost domestic origin, an unusually intense community, a company that incubated it and later stopped supporting it in the same way, a foundation created by technology giants, and a slow, difficult, symbolic entry into territories where C once seemed untouchable. Windows, Android and Linux have not abandoned C or C++, but they have opened the door to Rust in increasingly sensitive areas.
The word “revenge” works as a hook, but it falls short. What happened with Rust is not really the revenge of laid-off programmers. It is something deeper: the industry has accepted that patches, mitigations and audits are not enough to contain a class of errors that has caused crashes, exploits and security updates for decades. Rust has not gained ground because of fashion, but because the cost of continuing as before has become too high.
A language born out of frustration with memory bugs
The most repeated story about Rust begins in 2006, with Graydon Hoare climbing the stairs in Vancouver because the elevator in his building had failed again. The detail has been told so many times that it almost sounds like a fable, but it captures the frustration that gave rise to the language: seemingly small pieces of software, written in powerful languages, could fail absurdly because of memory-management errors.
C and C++ have been the foundation of operating systems, browsers, drivers, databases, compilers, video games and embedded software for decades. They are fast, flexible and allow programmers to control the machine with enormous precision. They also allow dangerous mistakes: buffer overflows, out-of-bounds access, use-after-free, double frees and dangling references.
Rust tries to preserve low-level control while changing the rules. Its ownership, borrowing and lifetime system forces the compiler to verify that code does not access invalid memory or introduce data races under conditions the language can check. That mechanism, known as the borrow checker, is one of Rust’s greatest strengths and also one of the reasons many developers find it difficult at first.
| Classic C/C++ problem | What Rust tries to prevent |
|---|---|
| Buffer overflow | Access beyond allowed bounds |
| Use-after-free | Use of memory that has already been freed |
| Double free | Freeing the same memory region more than once |
| Dangling pointers | References to data that no longer exists |
| Data races | Unsafe concurrent access |
| Null pointer dereference | Improper use of null references |
Rust does not eliminate every bug. Nor does it automatically make every program secure. unsafe exists, dependencies matter, there is FFI with C/C++, and logical errors cannot be prevented by any compiler. But it does reduce one of the most persistent families of vulnerabilities in modern software at the root.
Mozilla, Servo and the first major opportunity
Mozilla began officially sponsoring Rust in 2009. The language matched a real concern inside Firefox: browsers are huge pieces of software, exposed to untrusted content and written largely in C++. If a rendering engine processes millions of different web pages, any memory bug can become an entry point for an attacker.
That ambition led to Servo, an experimental browser engine designed to take advantage of Rust, parallelism and memory safety. For years, Rust and Servo grew together inside Mozilla. The language matured, moved past constant breaking changes and reached version 1.0 in 2015. That release was crucial because it promised backward compatibility, a requirement for any company considering production use.
| Milestone | Year | Why it mattered |
| Graydon Hoare starts Rust as a personal project | 2006 | First design of the language |
| Mozilla officially sponsors Rust | 2009 | The project gains resources and a team |
| Rust 1.0 | 2015 | Stability for real-world adoption |
| Mozilla layoffs | 2020 | Uncertainty over the project’s future |
| Rust Foundation | 2021 | More independent governance and funding |
| Rust enters Linux 6.1 | 2022 | First support inside the kernel |
| Google scales Rust in Android | 2021-2025 | Growing use in native components |
| Microsoft introduces Rust into parts of Windows | 2023 onward | Validation in massive system software |
The paradox arrived in 2020. Mozilla announced the layoff of around 250 people, roughly a quarter of its workforce. The cuts affected teams linked to Servo, WebAssembly, Rust and other projects. To many observers, it looked like a severe blow: the language Mozilla had incubated was left without the same corporate backing it had enjoyed for years.
But Rust was already bigger than Mozilla. The community had grown, major companies were using it, and the problem it tried to solve had not disappeared. It was becoming more visible.
The Rust Foundation and the moment the giants understood the risk
In February 2021, the Rust Foundation was created, with AWS, Google, Huawei, Microsoft and Mozilla as founding members. The message was clear: Rust could no longer depend on a single company. If several technology firms were building services, tools and infrastructure on top of the language, they also had to help sustain it.
This changed the perception of the project. Rust stopped looking like a Mozilla oddity and began to look like a more independent ecosystem, financially backed by companies that competed with each other but shared a concern: software security and reliability.
The underlying reason was an uncomfortable number. For years, Microsoft stated that around 70% of the vulnerabilities assigned CVEs in its software were related to memory safety. Google has reported a similar trajectory for Android: in 2019, memory safety issues represented 76% of Android vulnerabilities; by 2024, that share had fallen to 24%.
| Organization | Relevant memory-safety data |
| Microsoft | Around 70% of CVE-class vulnerabilities for years came from memory issues |
| Google Android | From 76% memory-safety vulnerabilities in 2019 to 24% in 2024 |
| NSA | Recommends memory-safe languages where possible |
| Rust Foundation | Brings together major players to sustain the language |
| Linux | Integrated initial Rust support in version 6.1 |
These numbers explain adoption far better than any revenge story. Large technology companies do not adopt a language out of sympathy for a community. They do so when the cost of not changing starts to exceed the cost of learning something new.
The culture clash: “rewrite it in Rust”
Rust also made enemies. Part of its community was perceived for years as overly evangelical. The phrase “rewrite it in Rust” became a meme because it appeared in discussions around almost any project: if something failed, someone suggested rewriting it in Rust. To many C and C++ developers, that sounded arrogant, simplistic or outright offensive.
The language itself did not make adoption effortless either. Rust requires developers to unlearn certain habits. A programmer used to C++ may feel that the compiler argues with every decision. The borrow checker does not negotiate: if it cannot prove a reference is valid, the program does not compile. That initial strictness causes rejection, but it also explains why so many developers later say the compiler forces them to think better.
| Common criticism of Rust | Technical response |
| It is hard to learn | It changes the mental model around memory and ownership |
| The community is intense | Enthusiasm has sometimes been counterproductive |
| Compilation is frustrating | The compiler catches errors before production |
| Not everything can be rewritten | Real adoption is usually gradual and incremental |
unsafe exists | It reduces the surface that requires strict auditing |
| C and C++ are still more mature | Rust is gaining ground in new code and critical modules |
The tension is not only technical. C has been at the center of computing for more than 50 years. C++ dominates large enterprise codebases, video games, browsers, embedded systems and high-performance software. Suggesting Rust in those spaces is not just suggesting a new tool; it is questioning decades of accumulated experience.
Linux: entering the cathedral written in C
The most symbolic battle has been Linux. The kernel is one of the most important software projects in the world, historically written in C and assembly, maintained by a technically demanding community with a long memory. Introducing Rust there was never going to be simple.
Initial Rust support arrived in Linux kernel 6.1. That did not mean Linux was going to be rewritten in Rust; rather, it meant the language could begin to be used in specific areas, especially drivers and new components. The idea was cautious: not to replace millions of lines of C, but to allow new code to benefit from memory-safety guarantees.
Resistance was real. Some veteran maintainers did not want to learn Rust or take responsibility for code written in a language they did not master. From their perspective, the problem was not only the language but the long-term maintenance burden: if a subsystem contains both C and Rust code, who reviews it, who fixes it at three in the morning, and what happens when an abstraction fails?
That debate remains legitimate. Rust brings safety, but it also adds organizational complexity. The industry cannot solve that with slogans. It needs documentation, tooling, training, clear boundaries around unsafe, interoperability with C and a community capable of maintaining the code for decades.
Microsoft and Google: security as the decisive argument
Microsoft has been one of the companies most openly defending the move toward memory-safe languages. Mark Russinovich, CTO of Azure, publicly recommended in 2022 that developers stop using C and C++ for new projects where possible and adopt Rust or other memory-safe languages. Microsoft has started introducing Rust into Windows components and cloud infrastructure projects, although exaggerated headlines should be avoided: Windows is not being rewritten entirely in Rust.
The real strategy is more incremental and more credible. Microsoft is using Rust in new parts or especially problematic areas where memory bugs have historically been expensive. Components related to graphics, fonts, drivers, virtualization or internal libraries are natural candidates because they combine low-level work, attack surface and performance requirements.
Google has followed a similar path in Android. Its stated goal is not to rewrite all existing C/C++ code, but to write new native code in Rust where appropriate. In Android 13, Google already reported around 1.5 million lines of Rust in AOSP and highlighted components such as Keystore2, Ultra-wideband, DNS-over-HTTP/3 and Android Virtualization Framework. In later publications, the company linked that transition to a clear reduction in memory-safety vulnerabilities.
| Company / project | Rust strategy |
| Microsoft | Gradual use in Windows components, Azure and system software |
| Google Android | New native code in Rust as an alternative to C/C++ |
| Linux | Rust support in drivers and new components |
| AWS | Use of Rust in infrastructure and support for the foundation |
| Mozilla | Origin and incubation of the language |
| NSA / CISA | Recommendation of memory-safe languages where viable |
There is a huge difference between rewriting everything and changing the default language for new critical code. The first option is usually unrealistic. The second can transform a codebase over time, because memory vulnerabilities often appear in new or recently modified code. If new code stops introducing that class of bugs, the curve begins to fall.
Why Rust will not dethrone C overnight
Enthusiasm for Rust can lead to a wrong conclusion: that C and C++ are finished. They are not. They remain essential in operating systems, compilers, graphics engines, firmware, video games, databases, telecommunications and industrial software. There are enormous amounts of tested, optimized, decades-old code that will not be replaced suddenly.
Rust is not the only answer either. Go, Swift, Java, C#, Python and other memory-safe languages play different roles. In low-level systems, Rust stands out because it offers control, performance and no mandatory garbage collector, but it is not always the best choice.
| Where Rust fits well | Where change is harder |
| New system code | Huge legacy C/C++ codebases |
| New drivers | Software with old certifications |
| Components exposed to attacks | Systems with closed toolchains |
| Cloud infrastructure | Teams without Rust experience |
| CLI tools and high-performance services | Code where unsafe would be too broad |
| Modern firmware and embedded systems | Hardware and SDKs tied to C |
The most likely future is not a world without C, but a world where C stops being the automatic choice for new critical code. Rust does not need to erase the past to win. It only needs to occupy the future where memory safety becomes a design requirement.
The real victory: changing the question
Ten years ago, the question was whether Rust was ready for production. Today the question is different: why write new critical code in C or C++ if there is an alternative that avoids many of their historical vulnerabilities? That shift in framing is Rust’s real victory.
The industry has moved from treating memory safety as an unavoidable problem to seeing it as an architectural decision. If a new product is written in a memory-unsafe language, the choice will increasingly need to be justified. Not because of dogma, but because of risk, maintenance cost, legal responsibility and regulatory pressure.
Rust did not “humiliate” C and C++. It forced them to share the center of the stage. It also forced giant companies to acknowledge that some of their technical debt cannot be fixed only with more tests, more patches or more audits. Sometimes the tool has to change.
The story began with a developer frustrated by a broken elevator and passed through layoffs, memes, resistance and conference arguments. But its provisional ending is much more serious: Rust is now part of the conversation around Windows, Android, Linux, cloud, national security and critical software.
It is not the revenge of laid-off programmers. It is the technical bill for 50 years of manual memory management. And for the first time in a long while, the industry seems willing to pay that bill by changing languages, little by little, where it hurts most.
Frequently asked questions
What is Rust?
Rust is a systems programming language designed to offer performance similar to C and C++, but with memory-safety and concurrency guarantees checked by the compiler.
Who created Rust?
Rust was started by Graydon Hoare in 2006 as a personal project while he was working at Mozilla. Mozilla began officially sponsoring its development in 2009.
Did Mozilla abandon Rust in 2020?
Mozilla carried out major layoffs in 2020 that affected teams linked to Rust, Servo and other projects. Rust did not disappear: in 2021, the Rust Foundation was created with support from AWS, Google, Huawei, Microsoft and Mozilla.
Why do Microsoft and Google use Rust?
Because many serious security issues come from memory errors in C and C++. Rust allows low-level code to be written while reducing that class of vulnerabilities, especially in new or sensitive components.
Will Rust completely replace C and C++?
Not in the short term. C and C++ will remain fundamental for years. What is changing is that Rust is gaining weight in new critical code, drivers, cloud infrastructure and components where memory safety is a priority.