C++, Where Are You?

On “Safe” C++ is almost two years old. I remember at that time I was kind of coping with the decline of C++, and that post captured some of the problems vividly. The topic of memory safety was in vogue, the Biden administration was issuing memos about memory safety (CISA), we were sort of struggling to integrate C++ with Rust, and it felt like resources to improve C++ and Clang were harder and harder to come by. I had this inexplicable feeling of being under pressure. I believed that the niche that C++ occupied would never go away, and that we were always going to need something to fill this niche, but it didn’t feel like folks around me appreciated this as much as I did.

The whole story of the 2010s C++ renaissance was actually a story of building static and dynamic bug-finding tools: ASan, coverage-guided fuzzers, Clang Static Analyzer, other sanitizers, and rolling up our sleeves and fixing bugs. Initially, this gave C++ a new lease on life. You could actually use C++ instead of Java, bank the efficiency gains, generate actionable memory bug reports, and fix them as needed. If you run closed-source network services like Google, you can treat memory safety as a reliability problem to be managed and measured, rather than 100% eradicated.

That was naive and incorrect. What actually happened was that we built a mountain of evidence for anyone who was listening to show that humans cannot be trusted to reliably manually manage memory. This is not a surprising result; it’s what I learned in university, if anyone remembers the Therac-25.

However, we collectively put our fingers in our ears, and sort of said, we can pile on the hardening layers, the sandboxes, the control flow integrity, and we’ll keep the whole ball of mud rolling. That was not sustainable. I remember someone in Chrome telling me that management really didn’t want every browser crash to turn into a P1 issue fire drill. I had this visceral reaction of “well, shit, I don’t know what to say, but it sure seems like you picked the wrong language! You gotta have the will to work hard if you want to use C++.” Of course, “will” here doesn’t come from engineers, it comes from directors and product managers who want to ship features, not tread water fixing bugs. They aren’t interested in a meticulous, beautiful, carefully designed, rigorous memory ownership model, they want to ship yesterday and stop thinking about it.

Fast forward to the deluge of AI-generated vulnerability reports we get today and the ease with which new models can simply brute force reverse engineer any binary, and it really makes me wonder: what are we doing here? I guess this post was prompted by the Anthropic formal verification post. That post isn’t really saying “you should use provably memory safe languages”, it’s more about formally verifying disassembled binaries, but it sure begs the question why one is using an unsafe language in the first place.

The WG21 committee does not seem to have become less dysfunctional in the last two years. It seems that the national bodies failed to approve the draft of the upcoming C++26 standard. Apparently it has to do with contracts, but it’s beyond my knowledge.

One of the things I used to hear from folks in the C++ standards committee was the question “will there be more C++ in the future, or is most of the important C++ already written?” With agents, I feel like the question is decidedly answered in the direction of, there will be more code in the future. If you’re going to write code with agents, why would you choose C++? The most important thing you need in a language that agents use is readability, clarity, and predictability. These are not things that C++ has. What it has instead are many different ways to construct clever abstractions that can make humans writing code more efficient.

I suppose what C++ still has going for it is the ability to: a) precisely control memory layouts and b) abstract those layouts over data types with templates. Performance predictability is often an important correctness criterion, so this is a real strength. However, I think we’ll soon find that clever folks using agents are going to invent other tools for expressing these ideas that humans will be able to read more easily than C++, which is legendarily user-hostile and “expert friendly.”

It’s an odd moment. The future is very unclear right now. People are sort of going through the stages of grief about the profession of programming in general, but in particular, I really feel like the future of C++ is looking dimmer and dimmer.

Upon reflection, it seems like there’s only one way forward, and that is to lean into formal verification, as covered in that Anthropic blog post. If LLVM is going to be a part of the compiler stack of the future, it is going to be because we create a formal specification of the LLVM intermediate language (working group), and create an optimizer that is verified and provably correct. And, while we’re at it, we really ought to implement LLVM in a memory safe language. In today’s age, we should be embarrassed by the pile of memory safety bugs you can find in the oss-fuzz issue tracker. The solution is not to whack those bugs one-by-one, it’s to write code in a way that doesn’t suffer from these failure modes.

LLVM IR is an interface that various other pieces of software interact with, and interfaces have a history of being extremely durable over time. For example, I’m typing this post on a laptop that runs an instruction set originally conceived in 1978 (x86). LLVM IR isn’t quite as irreplaceable as the x86 ISA, but it is an interface deeply integrated into the graphics stacks of all major operating systems. If we think about what’s good for the project and our community, we need to think about how to keep making that interface more useful and relevant, and right now that probably means safety and correctness.

This is some extreme late-night vagueposting, journaling, and thinking out loud, so please don’t interpret any of this as a plan of action. It is more of a reflection and an openness to change.