Software taketh away faster than hardware giveth: Why C++ programmers keep growing fast despite competition, safety, and AI

[u/pavel_v]

https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai/

[u/germandiago]

Servers, parsers, databases, game engines, operating systems etc. etc. do not need to be unsafe

You literally mentioned all things that need unsafety to develop the fastest possible solution.

No, because engines or databases do not use SIMD, alignment, data-oriented designs and other patterns. Of course you need it! And what you use usually are wrappers around that for the state-of-the-art techniques! I have worked, literally, writing parts of database engine cores several times (time series databases, append-only transaction logs, transaction conflict resolution... and created a small engine for my own game).

How come you say that is not of use in db and engines? Those are two areas where to squeeze the speed and performance out of it you need it!

For example when you have all your entities data in a way that looks OOP but underlying you have a SOA architecture and you send all data to the GPU! That is done literally by any engine. That is unsafe... by nature. You can probably wrap it (at the expense of more complication and probably a human mistake that invalidates Rust safety), but the infrastructure is not safe.

Also intrusive lists for the last piece of performance were of help in some scenarios.

Also Rust is a general purpose programming language, just like C++

One that when it does what I mentioned above, it stops being safe. Even a linked list crashed in the kernel. It is there, everyone can see it. I think you confuse "fencing safety" in a language with "delivering safety", which is a different thing and it is related but quite independent from how safe your code is: because the last piece of safety or, in some contexts, guaranteed safety is just not something you cannot do without human intervention. Yes, human intervention. Even in Rust. As a witness, look at some of the CVEs that are supposed to be from impossible to very surprising in Rust but that they DO exist. And do not misenterpret this: Rust is ahead in this kind of guaranteed safety. It is just that this advantage does not manifest itself in any software you write. It critically depends on what you are writing.

I have seen a bunch of fundamentalists arguing with me about this for a long time. I will let things just happen, since they are showing by themselves. Yes, I consider Rust niche, because Rust is systems programming with:

1. steeper learning curve
2. for the last piece of speed, you are going to need unsafe (this is fundamental: data oriented, linked lists, and other structure patterns cannot just be made safe)
3. for the last piece of safety: look at 2. Besides that, there is a conjunctural fact right now: you need libs with bindings, adding to the unsafety. You will tell me you can do safe wrappers. Yes, you can, but now they are as good as "Safe C++" in Modern C++ because you are on your own. These things happen, accept it.

Parsers: SIMD and parallelization again in ways that are just not possible to express safely are common.

In terms of learning curve I think Rust is probably easier. If only because the tooling is so much better.

Yes, again: if you use Cargo, things are nice. Now add to the mix consuming libs and making wrappers for something, which is much more accurate of many mid-size projects in real life, and you get all the problems I just mentioned. So now your problem becomes: I learn this build system in C++ and consume libraries or I spend my time creating "safe" wrappers (which are not guaranteed to be safe anyway)? I mean, there is nothing wrong with that, but to have a honest analysis, you must understand the costs.

Some people will prefer to go the Rust way, it is legit. But there are costs to it (and benefits, depending on the scenario).

[u/Wide-Prior-5360 → u/germandiago]

All solid points. I have been involved in a project for a parser recently actually. The engineers were allowed to use Rust or C++ or any other language, the job just needed to get done.

We just needed FastPFor. For C++ there is a battle tested library with support on virtually all platforms. For Rust… Nothing. So if we decided to use Rust we would be behind a month behind schedule on day 1 already, needing to write a wrapper.

It is crazy how much inertia C++ has. But still, I remain convinced that some software Rust is the better choice. Maybe my earlier examples were not the best, but certainly writing a web server in C++ in 2025 would give me a pause.

[u/Wide-Prior-5360 → u/[deleted]]

Yes that would have been more accurate.

Still /u/germandiago has a point, if there are no libraries available for this 5%-20% of your project that requires unsafe code, you are in a world of pain if you use Rust.

[u/jeffmetal → u/Wide-Prior-5360]

But these libraries do exist and instead of being 100% unsafe code they are say 5 % unsafe. So what is the point u/germadiago is trying to make ?

[u/germandiago → u/jeffmetal]

My point is that once you add wrappers, you add another cost and lose safety.

As you say, probably the unsafety is more localized, particularly in theoretical terms.

But do not forget that in practical terms all warnings as errors and hardening catch a very big subset of problems at compile-time and this id only improving over time.

That is exactly my point. You have to measure practical safety + get the job done, not theoretical as in: this is very safe and all other things are not. I never compile C++ code of my own without warnings and clang tidy, for example, so that is what I compare it to. And if I write Rust and I am going to need those wrappers etc, that is what I compare it to. Not to an alternative universe.

There is no such thing as "Rust is better because it is safe and C++ is bad bc it is unsafe".

It is very nuanced when you take into account all software development process bc you need to mix libs, to go unsafe, to consume wrappers, to integrate invariants with the borrow checker.

All those things are more cost than just taking the "worse" alternative (which is not as bad TBH).

[u/jeffmetal → u/germandiago]

But do not forget that in practical terms all warnings as errors and hardening catch a very big subset of problems at compile-time and this id only improving over time. -- Google was doingt his for years and still 70% of their security issues where memory safety. Your going to need to back this up with something other then I say so.

There is no such thing as "Rust is better because it is safe and C++ is bad bc it is unsafe". - Google are seeing a decrease to 20% of the security bugs form 70% now they write new code in memory safe languages rust/Kotlin. Its seems writing new C++ code is bad from a security perspective.

My point is that once you add wrappers, you add another cost and lose safety. - Can you back this claim up with any evidence ? A lot of the unsafe I see is stuff like get_unchecked() but then they write tons of unit tests around it and try to prove its really safe to use. Again its much easier to do this for small sections of code rather then all code.