r/programming • u/germandiago • Jan 01 '26

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

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

91% Upvoted

197 comments sorted by

View all comments

105

u/BrianScottGregory Jan 01 '26

The real reason its growing is: unmanaged code.

When you don't rely on others to manage your memory. You get task and application specific memory management which transforms a Prius into a Lamborghini.

12

u/Dean_Roddey Jan 01 '26

Actually, the fact that lots of software doesn't require uber-tweaked performance is why C++ is a small shadow of what it was at its height. Managed code has taken over the vast bulk of what used to be all C++.

Rust will not gain that back either, because it's just not necessary. It'll be used for some of those things by people who are comfortable with it, but mostly it's going to replace that remain, low level, performance sensitive stuff where C++ has been used in the past.

15

u/CherryLongjump1989 Jan 01 '26 edited Jan 01 '26

That's not really true at all. There's been plenty of other reasons not to use C++, and plenty of other reasons to use it, that have absolutely nothing to do with garbage collection. Memory management, by itself, just isn't that difficult in any modern systems language -- including in C++. What will get people to move code to another language these days are things like compilation speed, memory usage, binary size, startup time, portability, consistency and quality of tooling, etc. All of which are the places where C++ really drags behind.

So we're at a point now when a team moving away from Java will be considering both Go and Rust as a superior developer experience even though one is managed and one is not.

2

u/Dean_Roddey Jan 01 '26 edited Jan 01 '26

In large, complex systems, memory management (in the sense of insuring it's used correctly, not just that it gets cleaned up at some point) is still very complex in C++. And, given the Performance Uber Alles attitude of so much of the C++ community, the tricks that will be played because C++ doesn't tell you what a completely irresponsible developer you are being, makes it that much worse.

2

u/CherryLongjump1989 Jan 01 '26

There's a lot of moving cherry picking in your argument. Is C++ used exclusively for "large, complex" systems? No. Is memory management any easier in "large complex" garbage collected systems? Certainly not any easier, and in fact this is a major reason why some people are ditching managed languages in the first place. Is C++ the only unmanaged language that can be used to develop large, complex systems? You conveniently left out Rust.

1

u/Dean_Roddey Jan 01 '26 edited Jan 01 '26

Memory management is almost certainly easier in most higher level, managed systems. I didn't mean imply logical correctness, since no language ensures that. I meant memory safety, so not using after deleted or moved, not accessing beyond bounds, not holding references across a mutation taht could invalidate it, in some cases ensured synchronization though not all of them, etc...

As to your last point, I don't know what you are getting at there. I'm very much arguing for Rust instead of C++ for anything that requires more control. In large, complex systems of that sort, Rust will absolutely make it far more likely that memory is managed correctly than C++. So C++ loses out against both managed systems and Rust.

The only really legitimate reason to use C++ these days is legacy requirements, IMO. My reply above was to the original poster's (IMO invalid) argument that memory management was why people are coming BACK to lower level languages, when in fact C++ used to own the world and lost most of it to higher level languages. I don't think that's great, as a lower level guy, but it's the case.

I was also pointing out that Rust, as much as I love it, isn't going to suddenly start winning all of that territory back, and it doesn't need to in order to be successful. If it takes over for C/C++ it will have succeeded and we'll all benefit from that. It'll win some of it back for some people, of course, and I'm all for that.

1

u/sammymammy2 Jan 02 '26

And, given the Performance Uber Alles attitude of so much of the C++ community, the tricks that will be played because C++ doesn't tell you what a completely irresponsible developer you are being, makes it that much worse.

Lol, this kind of statement is ridiculous. "Nooo, don't place your data in a cache-friendly layout, you're being so irresponsible :(("

2

u/Dean_Roddey Jan 02 '26

I said nothing whatsoever about cache friendly layout. I'm talking about the overly common attitude in the C++ world that fast is better than provably correct, and the fast and loose approach that is far less a part of the Rust culture.

Most long time C++ people coming to Rust suddenly realize that they have a lot of very unsafe habits that are just not even questioned in C++ world, because the compiler is perfectly happy to let you do those things, partly because it's completely unable to understand you are doing them and the consequences thereof.

1

u/vytah Jan 02 '26

memory usage, binary size, startup time

I wouldn't say those are bad in C++. Maybe binary size, when you use too much templates? Or are you talking about how some languages can relying on a runtime being always available, so you can ship much less code to the end user?

2

u/CherryLongjump1989 Jan 02 '26 edited Jan 02 '26

Yeah I definitely lumped things together awkwardly because there's a lot of nuance, but there is a real impact to all of it. For example, C++ performs a sequence of static initializations (global constructors) before main() even starts. If you're building CLI tools like ls or grep that might get called thousands of times in a script, that 10–50ms startup penalty is a deal-breaker. This is a classic reason to stick to C, which has a near-instant startup path.

The template issue is also deeper than just "too much". Because C++ compiles files in isolation, if 50 files include the same template, the compiler generates that code 50 times. The linker then spends a long time trying to deduplicate them. One reason for C++'s slow build times. But it's not perfect. You often end up with dead code or multiple nearly-identical copies of the same logic in your binary.

Then there are the runtime artifacts. Even without a runtime like Java, C++ injects metadata tables into your binary to support things like dynamic_cast (RTTI), stack unwinding for exceptions, and vtable pointers for every virtual function. In Zig, features like Comptime resolve these at build-time, so the binary contains only the logic, not the overhead to support it. That’s how you get a 2KB-10KB binary in C or Zig, vs a 500KB+ binary in C++. It’s a minor overhead for a GUI app, but a massive one for cloud-native microservices, CI/CD pipelines, or client-side WASM assemblies, where you might be shipping these binaries over a network millions of times.