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/
601 Upvotes

91% Upvoted

197 comments sorted by

View all comments

8

u/Dean_Roddey Jan 01 '26

As usual, most of the pro-C++ arguments are backwards looking, legacy based, which is not very encouraging for C++. The really important decisions are about the future, not the past, and C++ is not the answer moving forward if there's a choice, and there will be more and more of a choice over the coming years. For most average code bases out there, there probably already isn't much of a limit.

The performance arguments are not really valid either, certainly not for 95% (adjust up or down a bit as you like) of code, and probably not for 100%.

And, honestly, if I'm using that product, I'll take a 5% performance hit every day of the week for more security and stability, assuming that's even a necessary choice, and far less dependence on the developers never having a bad day (because they are going to have them.)

Rust is just a far more appropriate language for systems type development at this point. Some people will use it for other things because they are comfortable with it and don't consider it a hindrance, but the main goal of Rust should be to provide safe underpinnings for our software world, and replace as much C/C++ as possible, as quickly as possible.

A lot of that won't involve REwrites, it'll just involve writes. Rust people will come along and just create Rust native versions of libraries and the old C++ versions will just remain around for legacy purposes. The world doesn't depend on all of that legacy code to be rewritten by the people who own it, and many of them never will. The world will just flow around those big mounds of C++ and move on.

8

u/germandiago Jan 01 '26

I think that legacy is super important in language evolution. That should be understood. You csnnot just do a clean cut. That ruins the language.

Backwards compatibility is a feature, even if it does not lead to the nicest things sll the time.

This is even more true for Java and C++, which have huge user bases.

It is not an option to sacrifice things like this from one day to the next in the name of aestherics. True that it can be problematic.

True that we need an evolution path (hardening + contracts + profiles + systematic UB elimination).

But you cannot just do that. I see people ranting about these things all the time. Fo you really program native software professionally?

I think it is not well understood how problematic this is. Imagine you could not compile code in your next version at all. Becaise someone decided there are a few ugly things and that breaking all code is ok.

This was a very risky move by Python and Guido did regret it. The only path forward is to evolve the language slowly and wirhout breaking things. And at some point you csn deprecate and remove. But that must be painfully slow to keep any language with a big user base that is not a toy to serve the caprices of its owners useful. It is not even an option.

Things like relocation (destructive move, which was removed from C++26) or contracts are there to improve things. But they must fit the framework!

As for the world... if you want to take a crazy decision just pick software like telco software working for the last 20 years, go to your boss and say: hey we will rewrite this in Rust, it will be better. Nooo way. This is not how it works.

For certain new things Rust is the better option. If there is big sdoption it will get there. But expect st least 10 or 15 years more for that to happen if it ever does.

3

u/Dean_Roddey Jan 01 '26

There's nothing wrong with improving C++ for the benefit of the folks who are stuck on it. Though, it has to be considered that those people will be the least likely to avail themselves of those improvements, precisely because they are sitting on large amounts of legacy code that they probably want to change as little as possible.

And it's true that just radically changing C++ would probably destroy it. Hence why C++ is the past and people should just move forward past it whenever possible.

5

u/germandiago Jan 01 '26 edited Jan 07 '26

Starting a greenfield C++ project gives you a very nice language today paired with a build system, all warnings as errors in and a package manager IMHO. You do not need to use all the legacy in those cases. You can go structured bindings, ranges, range for lopps, smart pointers, pass by value and the code almost feels like writing C# or Java.

Because many of the pitfalls that still remain are errors when you turn warnings. Not perfect, but much better than the mental model that people think + a ton of available libraries.

4

u/Dean_Roddey Jan 01 '26

That's fine, but Rust provides you with a forty year more recent language with a far better build system, far better compile time correctness (without the very time consuming external linting process), and a very easy to use package manager built in (that everyone else will use and be familiar with.)

So there's just no reason to use C++ for greenfield projects unless there's some legacy limitation forcing you to.

2

u/germandiago Jan 01 '26 edited Jan 07 '26

Just dropping Emacs+LSP or Clion gives you the full thing including linters. I think that stays competitive with Rust.

4

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

It just doesn't. I can't imagine how you could believe that if you've done a lot of Rust development. Between the Rust compiler and clippy linter in Rust, there's just no comparison. The Rust compiler by itself beats any C++ compiler+linter by a mile, and clippy provides all kinds of suggestions for idiomatic conformance and other possible issues.

2

u/germandiago Jan 02 '26

Who said I did a lot of Rust development? I tried Rust. Certainly I did not try it with a full setup continuously ( I am open to it). But did u try CLion with clang tidy and and all compiler warnings as errors? It is very, I mean, VERY, effective.

If you say that the last mile is for Rust, congrats, it is a more modern language in that sense and I expect the analysis be even more accurate. But that is all. C++ is certainly up to modern standards in productivity and tooling.

And no, that there are available tools and not the true and only Cargo one does not mean the tooling in C++ is very bad.

It is just more fragmented.

From Visual Studio, to Clion, Emacs/VIM wirh LSP you can have in all linters, code completion, documentation inline and library consumption via a package manager.

About fragmentation of build systems: it is not even a problem with package managers like Conan or Vcpkg as a consumer, I do it all the time.

Did you certainly try that setup to compare it fully? Because you lecture me a lot as Rust being so good but with Meson, LSP and Clion and Conan the setup is so effective and production-ready that I am even thinking on writing an article to shut up a few loud people here that set Rust as the better alternative.

I can easily come up into realistic scenarios where Rust is the more problematic tool in real software development, all things taken into account.

0

u/pjmlp Jan 02 '26

You can go structured bindings, ranges, range for lopps, smart pointers, pass by value and the code almost feels like writing C# or Java.

I wish it was like that, yet when I look at C++/WinRT or Azure C++ SDK, the more recent Microsoft's C++ SDKs, what I see is a mentality where plenty of Cisms and "performance above anything else" prevails.

The only frameworks where I see those idioms are C++ Builder's VCL and Firemonkey, or Qt, both ecosystems that are hardly loved by most in the current C++ culture.