Why C++ programmers keep growing fast despite competition, safety, and AI(herbsutter.com)
herbsutter.com
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/
77 comments
That's how all programming languages work. Have you used 100% of the features in any language you've used? Ever?
It's not the same though. The breadth is wildly different. In the case of things like JavaScript, C, or Go it can be said that you use -most of it- in a day to day to basis, sure, not the most magic, deep crap, but not the same can be said about C#, Rust, C++ etc on which you have a lot of features simply not used.
Rust hasn't grown 17 ways to initialize a variable yet. Most projects use most features.
When projects choose a subset of language features, it's dictated by their needs (like embedded programs disabling the standard library, or safety-critical libraries forbidding "unsafe" code out of caution). There are some people who vocally hate async, but their complaint is usually that everyone uses async even where it's unnecessary (meaning that it actually has very broad adoption).
This feels very different than having an unwanted C subset, some '98 features that were replaced in '11 and '13, with fixes for them in '20 and '26 and then projects taking years to settle on a new baseline, and still bickering whether exceptions may be allowed or not.
Rust has "editions" that let new projects disable old misfeatures (which it hasn't got many yet). Rust ecosystem is fully on board with the latest version.
When projects choose a subset of language features, it's dictated by their needs (like embedded programs disabling the standard library, or safety-critical libraries forbidding "unsafe" code out of caution). There are some people who vocally hate async, but their complaint is usually that everyone uses async even where it's unnecessary (meaning that it actually has very broad adoption).
This feels very different than having an unwanted C subset, some '98 features that were replaced in '11 and '13, with fixes for them in '20 and '26 and then projects taking years to settle on a new baseline, and still bickering whether exceptions may be allowed or not.
Rust has "editions" that let new projects disable old misfeatures (which it hasn't got many yet). Rust ecosystem is fully on board with the latest version.
not close to 100%, but i think i can say i ultilize most of feature of C, must more than C++.
As a Python dev, I really hate the whole “Pythonic” idea. There isn’t just one way to do this.
smeeagain2(2)
Honestly... who cares? The dictionary is pretty thick, but I still speak English without much trouble.
Open up an old Java code base, and your IDE will tell you to refactoring tons of code, as it was written in an old way it thinks you shouldn't use anymore, uses deprecated classes, etc.
Javascript is even more dramatic, where it will tell you to fix every single variable declaration, as people decided "var" was a mistake, and there is a whole new way of defining classes.
Javascript is even more dramatic, where it will tell you to fix every single variable declaration, as people decided "var" was a mistake, and there is a whole new way of defining classes.
Var wasn't "a mistake", and there's still (albeit niche) use cases where var makes sense. But for most cases, you do want to write a let/const declaration, even though they're not "free" technically.
I normally disagree with such broad remarks, but in the case of C++ I agree. I sometimes see a less common feature of Python used and have to remind myself of the syntax and its usage. With C++, I start any project with the idea that I will only use a small subset of the available features. When I review other's code I pretty much need a language reference available at all times until I can settle into their particular flavor of C++
I wonder if a subset of the language could be formalized, as some kind of opt-in decision. Like when TSR divided Dungeons & Dragons into D&D and AD&D...
> Every project must colonize a valley of the language, declare a dialect, and bit-fiddle their own thing.
this is really not true in my experience. I don't remember last time I worked a project which outright banned specific C++ features or had a "dialect".
this is really not true in my experience. I don't remember last time I worked a project which outright banned specific C++ features or had a "dialect".
> It might be a measure of popularity, but not of unity.
Neither of which are great measures probably. What about usefulness?
Neither of which are great measures probably. What about usefulness?
to this day i don’t know what people mean by “features”.
Lambdas are nice to have, just don’t nest them more than once.
I kinda wish things like std::variant had shorter syntax.
if anything i’m not a fan of c++ introducing language features as long verbose functions than to confidently make it an operator or a keyword.
Lambdas are nice to have, just don’t nest them more than once.
I kinda wish things like std::variant had shorter syntax.
if anything i’m not a fan of c++ introducing language features as long verbose functions than to confidently make it an operator or a keyword.
Yeah C++ isnt going away anytime soon - its not even in the COBOL phase of its lifetime despite the rise of Rust/Go as systems languages.
However it would be imperative for a push such as Carbon[1] to be similar to the kotlin to Java. A modernisation that simplifies , maintains backwards/forwards compatibility and reuses established libraries and tooling.
This however will need a entity that can champion and push it forward with a strong enough project to anchor it in the mainstream.The transitions are doable ,like Android dev from plain java to kotlin , or in OSX moving from Objective-C to Swift.
Additionally borrowing a robust batteries type standard library to reduce the sprawl of coding options and funnel greenfield projects into best practices and less boilerplate.
[1] https://www.infoworld.com/article/2337225/beyond-c-the-promi...
However it would be imperative for a push such as Carbon[1] to be similar to the kotlin to Java. A modernisation that simplifies , maintains backwards/forwards compatibility and reuses established libraries and tooling.
This however will need a entity that can champion and push it forward with a strong enough project to anchor it in the mainstream.The transitions are doable ,like Android dev from plain java to kotlin , or in OSX moving from Objective-C to Swift.
Additionally borrowing a robust batteries type standard library to reduce the sprawl of coding options and funnel greenfield projects into best practices and less boilerplate.
[1] https://www.infoworld.com/article/2337225/beyond-c-the-promi...
I think most people wouldn't call Go a systems language? Generally garbage collection lack of explicit memory access would put a language outside the category? Hard to write a device driver, for instance.
True although there is Ocaml which has been used in OS/driver/Hypervisor development while also having a GC.
I always thought the Go equivalents would have perfomance at parity - but never reallyseen that realised so far.
Well, if the chair of the C++ standards committee truly believes that C++ has no serious safety issues, it certainly explains why safety proposals have gone nowhere and "profiles" remain vaporware.
This is weirdly confident and defensive at the same time. If c++ is so great, why does it need to be so ardently defended and its very obvious problems handwaved away?
I take a very different view about the trajectory of languages given the current trends in software development. The more people rely upon agentic coding processes, the more they will demand faster compilation which will increasingly become a significant bottleneck on product velocity. The faster the llms get, the more important it is for the tools they use to be fast. Right now, I still think we are in an uncanny valley where llms are still slow enough that slow tooling does not seem that bad, but this is likely to change. People will no longer be satisfied asking their agent to make a change and come back in a minute or an hour. They will expect the result nearly instantaneously. C++ (and rust) compile times are too slow for the agent to iterate in the human reaction window so I believe that one of two things will happen over the next few years: llm progress will stall out or c++ and rust will nosedive in popularity.
I take a very different view about the trajectory of languages given the current trends in software development. The more people rely upon agentic coding processes, the more they will demand faster compilation which will increasingly become a significant bottleneck on product velocity. The faster the llms get, the more important it is for the tools they use to be fast. Right now, I still think we are in an uncanny valley where llms are still slow enough that slow tooling does not seem that bad, but this is likely to change. People will no longer be satisfied asking their agent to make a change and come back in a minute or an hour. They will expect the result nearly instantaneously. C++ (and rust) compile times are too slow for the agent to iterate in the human reaction window so I believe that one of two things will happen over the next few years: llm progress will stall out or c++ and rust will nosedive in popularity.
If [language] is so great, why does it need to be so ardently defended and its very obvious problems handwaved away?
Every language popular enough is like that.
Every language popular enough is like that.
i personally enjoy it because i just think it's a blast to write and typically understandable and explicit in its language.
with the caveat that i know it could be better. at this point i just think it's simpler than some of the stuff out there from a 'whats happening underneath the hood' perspective
with the caveat that i know it could be better. at this point i just think it's simpler than some of the stuff out there from a 'whats happening underneath the hood' perspective
> in the past three years the global developer population grew about 50%, from just over 31 million to just over 47 million
That's not really plausible. Unfortunately this is all you get on the methodology:
> Our methodology is based on two main pillars. First, we make use of reliable sources of developer numbers or direct indicators of their activity. This includes the number of GitHub accounts, Stack Overflow accounts, and employment statistics from the USA and the European Union. Second, we rely on our Global Developer Survey data, where we directly measure developer activity. So far, we've run 29 waves of this large survey, and in each, we reach more than 10,000 developers globally. We combine these two main sources to derive our estimates.
Plenty of space for them to screw up I think.
That's not really plausible. Unfortunately this is all you get on the methodology:
> Our methodology is based on two main pillars. First, we make use of reliable sources of developer numbers or direct indicators of their activity. This includes the number of GitHub accounts, Stack Overflow accounts, and employment statistics from the USA and the European Union. Second, we rely on our Global Developer Survey data, where we directly measure developer activity. So far, we've run 29 waves of this large survey, and in each, we reach more than 10,000 developers globally. We combine these two main sources to derive our estimates.
Plenty of space for them to screw up I think.
All the following statements can live without colliding.
- The current CPP version is extremely bloated
- CPP is not going away anytime soon
- The rise of Rust/Go/Zig is not fighting for CPP's seat
- You can target CPP code using any of these aforementioned languages
- Rust has never claimed to be "safer", it just makes it harder to write unsafe code
- The current CPP version is extremely bloated
- CPP is not going away anytime soon
- The rise of Rust/Go/Zig is not fighting for CPP's seat
- You can target CPP code using any of these aforementioned languages
- Rust has never claimed to be "safer", it just makes it harder to write unsafe code
> Rust/Go/Zig are not fighting for C++'s seat
Of course they are. Go less so, and Zig is really aiming for C. Rust is definitely meant to be a better alternative to C++.
> Rust has never claimed to be "safer"...
What? Of course it has (or Rust developers have; a language can't claim anything). And it is much safer.
Of course they are. Go less so, and Zig is really aiming for C. Rust is definitely meant to be a better alternative to C++.
> Rust has never claimed to be "safer"...
What? Of course it has (or Rust developers have; a language can't claim anything). And it is much safer.
Is there anything like a linter to force you to stay within some subset of c++? I like the language, but it is hard to avoid language constructs that are outdated or enforce a single (or a few) ways of doing things. A c++ subset could be nice.
We have clang-pretty
C++ profiles
So C, C++, and Rust programmers will be in demand, and other languages will shrink?
Does this also relate to rising DRAM costs, which will make memory-efficient code more usable as we head into an unseen future?
The costs of hardware will take a long time to percolate up to software architecture, if they ever do.
Until current computers cycle out, people will largely keep their 1-3 year old machine with sane amounts of memory. If we start seeing large numbers of machines in the wild with 4GB of memory, then maybe software will adapt. But that won't be for several years yet.
Until current computers cycle out, people will largely keep their 1-3 year old machine with sane amounts of memory. If we start seeing large numbers of machines in the wild with 4GB of memory, then maybe software will adapt. But that won't be for several years yet.
It definitely doesn't relate, the time horizon is wrong. The software needs much longer to change, and that change needs much longer to appear in the job market. Compared to the timeframe in the article DRAM prices have only just spiked up now.
Projecting into the future, hardware expenses have always been dwarfed by salaries. I don't expect that will change enough for it to be noticeable.
Projecting into the future, hardware expenses have always been dwarfed by salaries. I don't expect that will change enough for it to be noticeable.
Growth of CUDA gave it a second chance.
I guess TPUs and JAX give it a third chance, and maybe MLX a fourth, lmao.
A subset of the language keeps getting better and better you just need to ignore the demon of many decades of bloated nonsense. So for new projects it can even be pleasant until you run into something that makes you wanna go rust
smeeagain2(2)
I am french, good C++ scores on senior tests, still out of a job
I lack a degree though
I lack a degree though
Same city as you, same language. There's work but not much if you don't want to enter the consulting meat grinder.
I am willing to enter the consulting meat grinder, if you have any tip
I get regularly contacted my them, but they don't hire me
I get regularly contacted my them, but they don't hire me
Don't think I can give tips of value, as I'm "still young" and hold a pretty good diploma, so our positions are quite different. But my impression is that having a good enough portfolio (i.e. a meatier and more active GH) is a must if you lack the precious piece of paper.
[deleted]
Every project must colonize a valley of the language, declare a dialect, and bit-fiddle their own thing.
It might be a measure of popularity, but not of unity.