In 2018, Saudi journalist Jamal Khashoggi's fiancée's phone was hacked. Later that year, Khashoggi walked into the Saudi Arabian consulate in Istanbul to obtain documents related to his planned marriage, and left two hours later in a body bag.¹

It's easy to forget that the work we do affects real people. It's easy to feel, if only unconsciously, that the point of programming is to be mathematically beautiful or fun to use. It's easy to forget that buffer overflows aren't just bad in the abstract, but that sometimes, they get real people killed.

And it's about to get much, much worse.

In my day job, I work on a security team, so I have access to hard data and water cooler talk with colleagues at Google and elsewhere about agentic bug-finding models, which are behind what the security industry has coined the "vulnpocalypse". For the past few weeks, I've been repeatedly asked the same question: "Mythos. Is it really that bad?" In a word: Yes.

The point of this post isn't to adjudicate this claim, so in leiu of a serious argument, I'll just leave you with this graph courtesy of Firefox:

Many factors will determine the long-term equillibrium of vulnerability discovery,² but that equillibrium will take many years to reach. Regardless of how that plays out in the long term, the medium term impact is clear: memory-unsafe³ open-source⁴ software is not ready for high-quality bug-finding agents to be made widely available. It is expected that broad availability will happen at some point this summer,⁵ and when it does, few open source programs written in memory-unsafe languages will be safe from catastrophic exploits. Many actors will use these exploits to steal identities, or steal money, or commit other run-of-the-mill cyber crimes. But some will use these exploits to kill people.⁶ I am not being hyperbolic when I say that when these agents are made available, more people will die.

While memory safe languages are not a panacea, they will prevent the majority of these vulnerabilities (a typical estimate is 70%), and they will prevent the highest-impact of these vulnerabilities.⁷ This makes switching to memory safe languages a moral imperative. Alternatives such as Carbon are being developed, and other languages with different performance characteristics like Go or Java exist. However, when it comes to memory safe languages which are already in production and which impose no overhead relative to C or C++,⁸ Rust is the only option. Therefore, it is a moral imperative: Rust must succeed.

I am honored to call many people in the Rust community some of my closest friends. I have heard their stories at conferences, and over drinks, and on Zulip threads and Jitsi meetings. We have come to Rust for many different reasons (although they usually involve some form of nerd sniping). While the community has had its struggles, as any open source community does, it has always been an absolute blast – in our better moments, we have been kind to each other and written amazing software. To paraphrase Scott McNealy, we have "kicked butt, had fun, and changed computing forever."

I don't see why we can't keep having fun with Rust for the rest of our lives. But at the same time, we must acknowledge a hard truth: of the billions of people our software touches, only a tiny fraction know what a pointer is. To these people, it's irrelevant whether Rust is beautiful or fun. But for some of these people, if Rust doesn't succeed, they will die.

My dad and sister are both doctors, and I've always admired how they show up to work every day and face the weight of real, life-and-death consequences. The connection between their work and the lives of real people is immediate. One contrast that I've seen between their industry and our own is how they measure what is important.

Imagine that your parent had a worrisome lump on an annual physical and went to the radiologist to get it checked out. Imagine that the radiologist could choose a highly-accurate imaging technology, but instead they chose one with a high false-negative rate. You would be furious that this radiologist was jeopardizing your parent's life, and it wouldn't make you feel any better if the radiologist tried to reassure you that the technology they chose used a cleverer design, or had a better user interface, or made them feel nostalgic for when they were in med school. The radiologist's job is to treat your parent, and everything else is secondary.

Whatever the reason we each got into Rust, and whatever keeps us going, we have a new responsibility that most of us never asked for: people are now depending on us for their survival. They depend on Rust being secure. But more importantly, since Rust is already the most secure systems language in existence, they depend on Rust succeeding.

I wrote this post as a celebration that we have built a language so secure that people's lives depend on projects choosing it. We should be immensely proud of what we've accomplished.

But I also wrote it as a call to arms. Now more than ever, it is important that Rust succeed. In the coming months and years, we will need to make hard choices. We cannot be all things to all people. We will need to prioritize some use cases over others. We must think of progress and consensus as virtues in and of themselves. We must learn to recognize when having a consensus is more important than having the right consensus, and in these cases, to pick progress over stagnation. Whether it's C++ interop, or auditability, or any other un-glamorous feature which will nonetheless increase Rust adoption, we will have to hold our noses, wade into the muck, and get the work done.

I want to keep having fun, and thinking deep thoughts, and writing great code. I don't want to give up what has made Rust a joy to participate in.

But I also don't want people to die. If that means having a little less fun and being a little more serious, then I believe in our community's ability to rise to the occasion.