10 Years of Stable Rust: An Infrastructure Story

May 15, 2025/Graydon Hoare

A note from the Rust Foundation: Today, May 15, 2025, marks 10 years since the first stable release of Rust. To commemorate this milestone, we are excited to share the following guest blog contributed by Graydon Hoare, initial author of the Rust programming language.  

Rust turns 10 today, or at least it’s been 10 years since the 1.0 release. In this decade (and the near-decade of development before!) it has undergone growth and change I can barely comprehend the scale of. To say I’m surprised by its trajectory would be a vast understatement: I can only thank, congratulate, and celebrate everyone involved. It is deeply inspiring to have watched all that’s happened over that time and reflect on it from today’s vantage point.

While it’s tempting to talk about Rust’s journey in terms of the growth of “an idea” – perhaps starting from my amusing frustration with a broken elevator in 2006, as chronicled in this MIT technology review article – I think doing so misses the bigger picture.

In my view, Rust is a story about a large community of stakeholders coming together to design, build, maintain, and expand shared technical infrastructure. It’s a story with many actors:

  • The population of developers the language serves who express their needs and constraints through discussion, debate, testing, and bug reports arising from their experience writing libraries and applications.
  • The language designers and implementers who work to satisfy those needs and constraints while wrestling with the unexpected consequences of each decision.
  • The authors, educators, speakers, translators, illustrators, and others who work to expand the set of people able to use the infrastructure and work on the infrastructure.
  • The institutions investing in the project who provide the long-term funding and support necessary to sustain all this work over decades. 

All these actors have a common interest in infrastructure.

Infrastructure

Programming languages are a type of technical infrastructure: specifically, they are tools. Rust is a tool for building other infrastructure: network protocols, web servers, load balancers, telemetry systems, databases, codecs, cryptography, file systems, operating systems, virtual machines, interpreters, etc., etc.

I think “infrastructure” is a more useful way of thinking about Rust’s niche than arguing over the exact boundary that defines “systems programming”. As Deb Chachra writes in her excellent book on physical infrastructure:

“The more robust and reliable our infrastructural systems are, the less we think about them, and the more time and attention we put into other things.”

This is the essence of the systems Rust is best for writing: not flashy, not attention-grabbing, often entirely unnoticed. Just the robust and reliable necessities that enable us to get our work done, to attend to other things, confident that the system will keep humming along unattended.

Unfortunately, as Chachra also notes: “infrastructure becomes most visible when it fails.”

Rust’s initial implementation, its sustained investment, and its remarkable resonance and uptake all happened because the world needs robust and reliable infrastructure, and the infrastructure we had was not up to the task. Put simply: it failed too often, in spectacular and expensive ways. Crashes and downtime in the best cases, and security vulnerabilities in the worst. Efficient “infrastructure-building” languages existed but they were very hard to use, and nearly impossible to use safely, especially when writing concurrent code.

This produced an infrastructure deficit many people felt, if not everyone could name, and it was growing worse by the year as we placed ever-greater demands on computers to work in ever more challenging environments. Moore’s law was plateauing and multi-core systems were proliferating, as were low-power embedded and IoT systems, and everything was increasingly connected to the internet and vulnerable to attack. Infrastructure software was struggling, and it was increasingly clear that the tools used to build that infrastructure were a key culprit.

The opportunity for Rust was, from this perspective, fairly obvious. Those of us working in the field felt the situation acutely and wanted something better. Many of us had worked with functional languages, or other research languages, that offered a taste of a better world. But we were stuck with the tools we had.

Investment

We were stuck with the tools we had because building better tools like Rust was going to require an extraordinary investment of time, effort, and money. The bootstrap Rust compiler I initially wrote was just a few tens of thousands of lines of code; that was nearing the limits of what an unfunded solo hobby project can typically accomplish.

Mozilla’s decision to invest in Rust in 2009 immediately quadrupled the size of the team – it created a team in the first place – and then doubled it again, and again in subsequent years. Mozilla sustained this very unusual, very improbable investment in Rust from 2009-2020, as well as funding an entire browser engine written in Rust – Servo – from 2012 onwards, which served as a crucial testbed for Rust language features. There were dozens of engineers involved in these projects, working flat out for a decade.

And Mozilla was not the only party contributing. To take a few examples:

  • Rust sits atop LLVM, an even larger piece of shared technical infrastructure originally developed by researchers at UIUC and later funded by Apple, Qualcomm, Google, ARM, Huawei, and many other organizations.
  • Rust’s safe memory model derives directly from decades of research in academia, as well as academic-industrial projects like Cyclone, built by AT&T Bell Labs and Cornell.
  • Rust and Servo had multiple contributors working at Samsung, as part of their strategic interest in the projects.
  • Rust received many contributions both on and off the clock from interns, researchers, and professors at top academic research programming-language departments, including CMU, NEU, IU, MPI-SWS, and many others.
  • When Rust needed greater funding diversity by 2020, other companies stepped up. Amazon, Facebook, Google, Microsoft, Huawei, and others hired key developers and contributed hardware and management resources to its ongoing development.
  • These companies and many others also joined the Rust Foundation to contribute funding for physical infrastructure, legal and organizational structure, as well as grants and long-term strategic efforts of the project.
  • JetBrains and the Rust-Analyzer OpenColletive essentially paid for two additional interactive-incremental reimplementations of the Rust frontend to provide language services to IDEs – critical tools for productive, day-to-day programming.
  • Hundreds of companies and other institutions contributed time and money to evaluate Rust for production, write Rust programs, test them, file bugs related to them, and pay their staff to fix or improve any shortcomings they found. 
  • Last but very much not least: Rust has had thousands and thousands of volunteers donating years of their labor to the project. While it might seem tempting to think this is all “free”, it’s being paid for! Just less visibly than if it were part of a corporate budget.

All this investment, despite the long time horizon, paid off. We’re all better for it.

Looking Back

The baby Rust I wrote in 2006-09 had essentially no type checker at all, generated abysmally slow code, ran on only 3 platforms (all 32-bit x86 so really just one), and could barely perform basic IO functions or run small demonstration tests. Bootstrap runs in 2011 took hours.

By the time 1.0 was released in 2015, Rust had been overhauled so thoroughly and by so many people it was hardly recognizable as the same language. It had an advanced polymorphic type system developed by world experts, it performed well enough to regularly beat C++, it ran on most major LLVM targets, and you could write a fairly convincing web browser engine in it.

But that Rust was still uncomfortably primitive by today’s standards. Rust 1.0 might have been “production ready” (or at least “stable”) but it was hardly “mainstream ready”, it still didn’t have:

  • A high-quality IDE experience. Rust 1.0 users were limited to the still-new racer auto-completion tool, whereas today Rust ships with an industrial-strength LSP server rust-analyzer.
  • A vast package ecosystem and a mature version of cargo to manage it. At 1.0 there were only about 2000 crates on crates.io and cargo was still very new: six months old and barely 14,000 lines of code. Today’s cargo, at more than six times that size, has become the standard against which all other package managers are measured, and crates.io has grown to over 180,000 crates.
  • A standard method of doing high-performance IO or networking. Today’s Rust programs excel at network-traffic processing, but at 1.0, neither the language’s necessary async/await machinery nor runtimes like Tokio that use that machinery existed.
  • Numerous quality-of-life improvements in the language, which today make it easier to write and understand code. Everything from the result-propagating ? operator to ergonomic improvements in pattern-matching and module systems greatly improved the daily experience of writing Rust code. And of course, Rust’s famous diagnostic error messages are the envy of every other language in the world. 
  • An agreed-on specification of the language, such as the recently adopted FLS (and upcoming official spec). Especially problematic was the lack of any description whatsoever of what unsafe code meant, or the parameters of its correctness, such as that provided by the RustBelt project and the MIRI interpreter.
  • For that matter: Rust 1.0 didn’t have MIR at all! The entire mid-section of the compiler acted on the AST and then lowered directly to LLVM. This meant many optimizations, error analyses, and even high-value features were practically impossible to implement. Everything from const evaluation to non-lexical lifetimes depended on shifting to MIR.
  • The substantial growth we’ve seen in project-maintained libraries. The std library grew from 40,000 lines of code to 120,000, and the core library grew from 15,000 lines to 79,000. To put that in perspective, the libraries today are now larger than the compiler was at 1.0! Every release has seen new features, API improvements, refactorings, documentation, stabilizations, and adaptations to language changes and user feedback.

Importantly: since all of this was done in the post-1.0 environment, every single change passed an exhaustive testsuite, and every release was regression-tested against a significant fraction of the public crate ecosystem, and with very few exceptions any change that broke existing code was rejected. As the 1.0 release announcement promised, Rust remained stable without stagnating. Existing code, in almost all cases, just kept humming along, like good infrastructure should.


To put some concrete numbers on the enormous volume of sustained, non-breaking change:

  • During the years before 1.0, the Rust repository recorded 40,000 changes. In the years since there have been 246,000 additional changes. That is approximately 2.8 changes merging per hour, every hour of every day for 10 years.
  • The set of contributors to that repository expanded from just under 1,000 at 1.0 to around 6,700 today.
  • Those contributors have closed over 47,000 issues across 140,000 pull requests.
  • At 1.0 there were around 1,100 RFCs, the documents used to manage changes to the language. As of today, there are 3,772 RFCs.
  • There have been 87 full release cycles, mostly on time every six weeks, since 1.0.
  • There have also been 3 major “editions” bundling together sets of opt-in incompatible changes (localized to the opted-in crate, so as not to break any existing code).
  • The set of crates each release is tested against grew from around 2,500 at 1.0 to around 587,000 today.

As impressive as all the changes to the software artifacts are, equally impressive are all the changes that happened beyond the software. These are essential to fulfilling Rust’s role as infrastructure for the community it serves:

  • Many different courses and teaching modules were written and taught, from Rust By Example and Rustlings to Google’s Comprehensive Rust course, Rust has seen an enormous growth in available learning materials since 1.0.
  • Extensive work was done on the Rust project’s organizational and operational state: the Rust Foundation was formed as a legal and financial entity, retaining ownership of key legal rights such as the trademark and providing operational staffing and stewardship of key resources such as the project’s integration-testing infrastructure and crates.io.
  • At the same time, the project’s internal governance system underwent multiple reorganizations, culminating in today’s leadership council system.
  • The set of stakeholders and institutions advising, advocating, and shaping the ongoing requirements for Rust greatly expanded, and now includes those involved in industrial standards for safety-critical software, and even national governments and agencies.

Looking ahead

To quote Deb Chachra once more:

“First, the construction of systems like these is predicated on the belief that there will be a stable community in place to benefit from them, typically for decades to come. They’re an investment into a vision of a shared future. They are, by their nature, about continuity and time. Next, the economic argument for their value is strengthened by universal provision because the capital and operating costs can be amortized over more users.”

Rust today is the result of significant investments made by forward-looking institutions and the efforts of thousands of individuals who shared a belief in the long-term payoff of what they were building. It may seem like 10 (or 15 or 20) years is already a long time for Rust to have existed, but C++ is 40 years old and FORTRAN is almost 70. Rust might last that long, or longer.

When reflecting on future of Rust, one should therefore focus on the following:

  • Many of the thousands of contributors to Rust have had to step away over the years, due to exhaustion or competing demands. I only lasted 7 years! While the project has always attempted to cultivate a broad community (starting with its early code of conduct) it still has to spend effort attracting and integrating new people into its processes, and managing transitions from each set of maintainers to the next.
  • The same is true for sponsoring institutions. As much as possible, the project needs to ensure that each successive generation of maintainers finds steady and diversified streams of support, and ideally full-time, Rust development employment for those seeking it.
  • As the scale of the project grows, it will become even more critical to maintain reliability and compatibility. The cost and number of people affected by any mistake will grow, as will the seriousness of institutions that have staked their operations on Rust tools and code. The project should assume an ever-increasing bar for quality, for certainty that each change is correct and that all possible stakeholders have been considered and consulted with. This should include investment in ever-greater reliability technology, including the many emerging formal methods projects built on Rust.

Of course, one need not look far into the future to imagine things that will need doing. The project already has a very full plate! While 47,000 issues may have been closed, there remain over 10,000 still open, with new ones opened daily. Many of those 3,772 RFCs are still open and in need of attention, hundreds of pending changes are (always) ready for review and merging, and every six weeks a new release needs to be shepherded through the process.

That sustained, controlled, and frankly astonishing throughput of work is really something to behold. It has set a new standard for what good tools, good processes, and reliable infrastructure software should be like. Everyone involved should be proud of what they’ve built.

Special thanks to C.S. Tysor for feedback on earlier drafts of this post.

Posted in

Graydon Hoare

Graydon Hoare is the initial author of the Rust programming language.