Most of us, if we found ourselves trudging up 21 flights of stairs, would just get pissed off and leave it there. But Hoare decided to do something about it. He opened his laptop and began designing a new computer language, one that he hoped would make it possible to write small, fast code without memory bugs. He named it Rust, after a group of remarkably hardy fungi that are, he says, “over-engineered for survival.”
Seventeen years later, Rust has become one of the hottest new languages on the planet—maybe the hottest. There are 2.8 million coders writing in Rust, and companies from Microsoft to Amazon regard it as key to their future. The chat platform Discord used Rust to speed up its system, Dropbox uses it to sync files to your computer, and Cloudflare uses it to process more than 20% of all internet traffic.
When the coder discussion board Stack Overflow conducts its annual poll of developers around the world, Rust has been rated the most “loved” programming language for seven years running. Even the US government is avidly promoting software in Rust as a way to make its processes more secure. The language has become, like many successful open-source projects, a barn-raising: there are now hundreds of die-hard contributors, many of them volunteers. Hoare himself stepped aside from the project in 2013, happy to turn it over to those other engineers, including a core team at Mozilla.
It isn’t unusual for someone to make a new computer language. Plenty of coders create little ones as side projects all the time. But it’s meteor-strike rare for one to take hold and become part of the pantheon of well-known languages alongside, say, JavaScript or Python or Java. How did Rust do it?
To grasp what makes Rust so useful, it’s worth taking a peek beneath the hood at how programming languages deal with computer memory.
You could, very crudely, think of the dynamic memory in a computer as a chalkboard. As a piece of software runs, it’s constantly writing little bits of data to the chalkboard, keeping track of which one is where, and erasing them when they’re no longer needed. Different computer languages manage this in different ways, though. An older language like C or C++ is designed to give the programmer a lot of power over how and when the software uses the chalkboard. That power is useful: with so much control over dynamic memory, a coder can make the software run very quickly. That’s why C and C++ are often used to write “bare metal” code, the sort that interacts directly with hardware. Machines that don’t have an operating system like Windows or Linux, including everything from dialysis machines to cash registers, run on such code. (It’s also used for more advanced computing: at some point an operating system needs to communicate with hardware. The kernels of Windows, Linux, and MacOS are all significantly written in C.)
“It’s enjoyable to write Rust, which is maybe kind of weird to say, but it’s just the language is fantastic. It’s fun. You feel like a magician, and that never happens in other languages.”
Parker Timmerman, software engineer
But as speedy as they are, languages like C and C++ come with a trade-off. They require the coder to keep careful track of what memory is being written to, and when to erase it. And if you accidentally forget to erase something? You can cause a crash: the software later on might try to use a space in memory it thinks is empty when there’s really something there. Or you could give a digital intruder a way to sneak in. A hacker might discover that a program isn’t cleaning up its memory correctly—information that should have been wiped (passwords, financial info) is still hanging around—and sneakily grab that data. As a piece of C or C++ code gets bigger and bigger, it’s possible for even the most careful coder to make lots of memory mistakes, filling the software with bugs.
“In C or C++ you always have this fear that your code will just randomly explode,” says Mara Bos, cofounder of the drone firm Fusion Engineering and head of Rust’s library team.
In the ’90s, a new set of languages like Java, JavaScript, and Python became popular. These took a very different approach. To relieve stress on coders, they automatically managed the memory by using “garbage collectors,” components that would periodically clean up the memory as a piece of software was running. Presto: you could write code that didn’t have memory mistakes. But the downside was a loss of that fine-grained control. Your programs also performed more sluggishly (because garbage collection takes up crucial processing time). And software written in these languages used much more memory. So the world of programming became divided, roughly, into two tribes. If software needed to run fast or on a tiny chip in an embedded device, it was more likely to be written in C or C++. If it was a web app or mobile-phone app—an increasingly big chunk of the world of code—then you used a newer, garbage-collected language.
With Rust, Hoare aimed to create a language that split the difference between these approaches. It wouldn’t require programmers to manually figure out where in memory they were putting data; Rust would do that. But it would impose many strict rules on how data could be used or copied inside a program. You’d have to learn those coding rules, which would be more onerous than the ones in Python or JavaScript. Your code would be harder to write, but it’d be “memory safe”—no fears that you’d accidentally inserted lethal memory bugs. Crucially, Rust would also offer “concurrency safety.” Modern programs do multiple things at once—concurrently, in other words—and sometimes those different threads of code try to modify the same piece of memory at nearly the same time. Rust’s memory system would prevent this.
When he first opened his laptop to begin designing Rust, Hoare was already a 10-year veteran of software, working full time at Mozilla. Rust was just a side project at first. Hoare beavered away at it for a few years, and when he showed it to other coders, reaction was mixed. “Some enthusiasm,” he told me in an email. “A lot of eye-rolls and ‘This will never work’ or ‘This will never be usable.’”
Executives at Mozilla, though, were intrigued. Rust, they realized, could help them build a better browser engine. Browsers are notoriously complex pieces of software with many opportunities for dangerous memory bugs.
One employee who got involved was Patrick Walton, who’d joined Mozilla after deciding to leave his PhD studies in programming languages. He remembers Brendan Eich, the inventor of JavaScript, pulling him into a meeting at Mozilla: “He said, ‘Why don’t you come into this room where we’re going to discuss design decisions for Rust?’” Walton thought Rust sounded fantastic; he joined Hoare and a growing group of engineers in developing the language. Many, like Mozilla engineers Niko Matsakis and Felix Klock, had academic experience researching memory and coding languages.
several engineers on the project. These included Patrick Walton (1), who had joined Mozilla after deciding to leave his PhD studies in programming languages; Niko Matsakis (2) and Felix Klock (3), both of whom had academic experience researching memory and coding languages; and Manish Goregaokar (4), who currently runs Rust’s developer tools team.
COURTESY PHOTOS
In 2009, Mozilla decided to officially sponsor Rust. The language would be open source, and accountable only to the people making it, but Mozilla was willing to bootstrap it by paying engineers. A Rust group took over a conference room at the company; Dave Herman, cofounder of Mozilla Research, dubbed it “the nerd cave” and posted a sign outside the door. Over the next 10 years, Mozilla employed over a dozen engineers to work on Rust full time, Hoare estimates.
“Everyone really felt like they were working on something that could be really big,” Walton recalls. That excitement extended outside Mozilla’s building, too. By the early 2010s, Rust was attracting volunteers from around the world, from every nook of tech. Some worked for big tech firms. One major contributor was a high school student in Germany. At a Mozilla conference in British Columbia in 2010, Eich stood up to say there’d be a talk on an experimental language, and “don’t attend unless you’re a real programming language nerd,” Walton remembers. “And of course, it filled the room.”
Through the early 2010s, Mozilla engineers and Rust volunteers worldwide gradually honed Rust’s core—the way it is designed to manage memory. They created an “ownership” system so that a piece of data can be referred to by only one variable; this greatly reduces the chances of memory problems. Rust’s compiler—which takes the lines of code you write and turns them into the software that runs on a computer—would rigorously enforce the ownership rules. If a coder violated the rules, the compiler would refuse to compile the code and turn it into a runnable program.
Many of the tricks Rust employed weren’t new ideas: “They’re mostly decades-old research,” says Manish Goregaokar, who runs Rust’s developer-tools team and worked for Mozilla in those early years. But the Rust engineers were adept at finding these well-honed concepts and turning them into practical, usable features.
As the team improved the memory-management system, Rust had increasingly little need for its own garbage collector—and by 2013, the team had removed it. Programs written in Rust would now run even faster: no periodic halts while the computer performed cleanup. There are, Hoare points out, some software engineers who would argue that Rust still possesses elements that are a bit like garbage collection—its “reference counting” system, part of how its memory-ownership mechanics work. But either way, Rust’s performance had become remarkably efficient. It dove closer to the metal, down to where C and C++ were—yet it was memory safe.
Removing garbage collection “led to a leaner and meaner language,” says Steve Klabnik, a coder who got involved with Rust in 2012 and wrote documentation for it for the next 10 years.
Along the way, the Rust community was also building a culture that was known for being unusually friendly and open to newcomers. “No one ever calls you a noob,” says Nell Shamrell-Harrington, a principal engineer at Microsoft who at the time worked on Rust at Mozilla. “No question is considered a stupid question.”
Part of this, she says, is that Hoare had very early on posted a “code of conduct,” prohibiting harassment, that anyone contributing to Rust was expected to adhere to. The community embraced it, and that, longtime Rust community members say, drew queer and trans coders to get involved in Rust in higher proportions than you’d find with other languages. Even the error messages that the compiler creates when the coder makes a mistake are unusually solicitous; they describe the error, and also politely suggest how to fix it.
“The C and C++ compiler[s], when I make mistakes, make me feel like a terrible person,” Shamrell-Harrington says with a laugh. “The Rust compiler is more like it’s guiding you to write super-safe code.”
By 2015, the team was obsessed with finally releasing a “stable” version of Rust, one reliable enough for companies to use to make software for real customers. It had been six years since Mozilla took Rust under its wing, and during that long development time, coders had been eager to try demo versions, even though they could be janky: “The compiler broke all the time,” Goregaokar says. Now it was time to get a “1.0” out into the world.
Walton remembers spending hours hunched over his laptop. Klabnik “wrote like 45 pages of documentation in the last two weeks,” he recalls. On May 15, 2015, the group finally released the first version, and groups of Rust nerds gathered for parties worldwide to celebrate.
Mozilla’s investment soon began to pay off. In 2016, a Mozilla group released Servo, a new browser engine built using Rust. The next year, another group used Rust to rewrite the part of Firefox that rendered CSS, a language used to specify the appearance of websites. The change gave the browser a noticeable performance boost. The company also used Rust to rewrite code that handled MP4 multimedia files and had been at risk of admitting unsafe, malicious code.
Rust developers—“Rustaceans,” as they’d begun to call themselves—soon heard from other companies that were trying out their new language.
Samsung coders told Klock, who was working from Mozilla’s office in France, that they’d begun using it. Facebook (later known as Meta) used Rust to redesign software that its programmers use to manage their internal source code. “It’s hard to overstate how important it is,” says Walton, who works for Meta today.
Soon Rust was appearing at the core of some remarkably important software. In 2020, Dropbox unveiled a new version of its “sync engine”—the software that’s responsible for synchronizing files between users’ computers and Dropbox’s cloud storage—that engineers had rewritten in Rust. The system was originally coded in Python, but it was now handling billions of files (and trillions of files synchronized online). Rust made it easier—even pleasant—to handle that complexity, says Parker Timmerman, a software engineer who recently left Dropbox.
“It’s enjoyable to write Rust, which is maybe kind of weird to say, but it’s just the language is fantastic. It’s fun. You feel like a magician, and that never happens in other languages,” he says. “We definitely took a big bet—it’s a new technology.”
Some firms were discovering that Rust eased their terror about memory bugs; Mara Bos used Rust to completely rewrite her company’s software for controlling drones, which was originally written in C++.
Others were discovering the joys of abandoning garbage collection. At Discord, engineers had long been annoyed that the garbage collector in Go—the language they’d used to build critical chunks of their software—would slow things down. Their Go software would carry out the procedure roughly every two minutes, even though the Discord engineers had written things so carefully there was no garbage to be collected. In 2020, they rewrote that system in Rust, and discovered it now ran 10 times faster.
Even executives and engineers at Amazon Web Services, the tech giant’s cloud computing platform, have become increasingly convinced that Rust can help them write safer, faster code. “Rust is uniquely positioned to give advantages there that I can’t get from other languages. It gives you multiple superpowers in one language,” says Shane Miller, who created a Rust team at AWS before leaving the firm last year.
Perhaps most crucially for the cloud computing giant, a study of Rust-based code found it runs so efficiently that it uses half as much electricity as a similar program written in Java, a language commonly used at AWS. “So I could create a data center that runs 2X the workloads that I have today,” Miller says. Or do the same work in a data center that’s half the size, letting you tuck one into a city instead of planting it in an exurban field.
Some longtime contributors have been made a bit nervous by Rust’s success. As tech giants adopt the language, they’re also gaining more influence over it. They have enough money to pay engineers to work full time developing Rust; several of the leaders of Rust teams, for example, are employees at Amazon and Microsoft. Other valuable contributors have to do their Rust work in their spare time; Bos, for example, does contract work on Rust for Huawei, in addition to running her drone startup, but her role as the head of Rust’s library team is unpaid.
It’s a common dynamic with open-source projects, Bos says: big companies can afford to participate more, and they can nudge a project toward solving problems that they care about but smaller firms may not. “It does give them some influence,” she says. But thus far, she says, none of the firms have done anything to ring alarm bells. Klabnik, who’s raised concerns about Amazon’s involvement in Rust (and who left Rust last year), agrees. “Do I worry about it? Yeah. Do I think it’s particularly bad or in a worse spot than many other places? No.”
In 2021, the major tech firms paid to set up a nonprofit Rust Foundation to support volunteer coders. Led for its first two years by Miller, it offers $20,000 grants for programmers who want to work on some major feature of Rust, and “hardship” grants for contributors in short-term financial need. It’s also funding the servers that host Rust’s code, and paying for a tech firm to be available to ensure that they run 24/7. In classic open-source style, that work was previously done by “two volunteers who were basically on call 50% of their lives,” Miller says. “One of them was a student in Italy.”
The language has, improbably and rapidly, grown up. If Rust was born in 2006, it is now heading out of its adolescence and into maturity. Auto firms are adopting Rust to build crucial code that runs cars; aerospace companies are taking it up too. “It’s going to be used everywhere,” predicts Dropbox’s Timmerman. Microsoft executives have even publicly suggested what many other tech firms are likely pondering behind closed doors: that it will use Rust more and more for new code—and C and C++ less and less. Ultimately maybe never.
All that old C and C++ code that’s already kicking around won’t vanish; it’ll remain in use, likely for many decades. But if Rust becomes the common way to write new code that needs to be fast and bare-metal, we could begin to notice that—very gradually, year by year—our software landscape will grow more and more reliable: less crash-prone, less insecure.
That would astonish no one more than Hoare. “Most languages,” he says, “just die on the vine.”
Clive Thompson is a science and technology journalist based in New York City and author of Coders: The Making of a New Tribe and the Remaking of the World.
