Why C++ programmers keep growing fast despite competition, safety, and AI
30 points
11 hours ago
| 9 comments
| herbsutter.com
| HN
nacozarina
5 hours ago
[-]
C++ is so bloated that every project must outlaw multiple parts of it from being used on their project. Using the whole language is an explicit antipattern.

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.

reply
estimator7292
4 hours ago
[-]
That's how all programming languages work. Have you used 100% of the features in any language you've used? Ever?
reply
smeeagain2
3 hours ago
[-]
Hell, look at Rust. Try bootstrapping that POS with verbose logging enabled, and watch the screenfuls of command line options scrolling by for every source file in the giant multi hour compile. It's got 30 years of cruft packed into a "new" language. Just think of how ridiculously complex it would become after an actual 30 years of real world use. That's the garbage you want me to replace C or C++ with? LOL

C++ sucks, but I'll take it over Rust any day.

reply
ahartmetz
2 hours ago
[-]
Yeah, no. That is not a fair description of Rust. It's got far fewer mistakes than C++ and, get this, it has a mechanism for tentative features that can get revised and fixed based on usage experience. It doesn't always work especially for far-reaching decisions (I hear that async is considered problematic), but it prevents a lot of stupid mistakes that C++ is carrying along forever - with a few exceptions (e.g. garbage collection support, extern templates) and some very notable inclusions (the kind of botched module system, suboptimal unordered_map, std::string which is more of a byte/word array).

I like C++ because I like the fairly unique high performance low level feature set, not because I particularly like most of the detailed design decisions that went into it. Rust has the same goals, but is better thought out IMO. I'm sure that I will find some more trouble in Rust as I use it more, but so far the impression is quite good. I have become pretty good at writing C++ code that works after fixing one or two stupid bugs, and that works even better in Rust, mostly without the stupid bugs because you can't forget to null-check a pointer to another subsystem while starting up etc.

reply
smeeagain2
24 minutes ago
[-]
You'll learn. One way or another, you'll learn.

My description of the red herring that is Rust stands as written.

I also wasn't a fan of Python or Javascript back in the day, for very sound reasons that your type will always just brush away as meaningless, yet in time these languages have proven to be just as flawed as I always knew they were. And yes, C++ is garbage too, as I've also understood, but you don't want to hear me when I tell you Rust is NOT any kind of solution.

In fact it's a great big joke that is obvious with the least bit of actual analysis. Question: Rust is built on top of LLVM, which is written in which language? ___. Fill in the blank. Hint: it's the language that is supposedly going to be replaced by Rust. lol.

Rust, the language that is so obviously great the only way to put it everywhere is to force it on people; force it into the kernel against big objections from smart engineers, force it into the browser with the power of Google, force it into the heart of Mesa through writing a critical component in it, etc.

Sort of like systemd, right? So obviously great that people have to be forced to use it, until the old guard has died off or been silenced and all that's left is the brainwashed youth who never knew anything different. Same old tactics the liars and crooks always used to force their garbage down on people and make them think it was their own idea.

Always the herd marches in the direction its owners desire, while each individual creature thinks "his" ideas are truly his own and he himself decided which direction he is to travel in.

I've long had the experience of people "suddenly beginning to discover" things I clearly understood on day one, decades ago. I've also long had the experience of never being given any credit for my actual understanding, instead constantly being told I'm wrong, stupid, have no idea what I'm talking about, blah blah. This is exactly why I don't spend much time hanging out with the hoi polloi anymore. (You Are Here.)

reply
Bridged7756
3 hours ago
[-]
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.
reply
nitwit005
2 hours ago
[-]
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.

reply
steve1977
41 minutes ago
[-]
> It might be a measure of popularity, but not of unity.

Neither of which are great measures probably. What about usefulness?

reply
psyclobe
1 hour ago
[-]
Honestly... who cares? The dictionary is pretty thick, but I still speak English without much trouble.
reply
sidewndr46
3 hours ago
[-]
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++
reply
emigre
2 hours ago
[-]
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...
reply
i_am_a_peasant
4 hours ago
[-]
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.

reply
norir
1 hour ago
[-]
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.

reply
rzerowan
4 hours ago
[-]
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...

reply
helltone
2 hours ago
[-]
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.
reply
jokoon
2 hours ago
[-]
I am french, good C++ scores on senior tests, still out of a job

I lack a degree though

reply
singularity2001
4 hours ago
[-]
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
reply
smeeagain2
3 hours ago
[-]
I like my OS how I like my cars: rust free.
reply
vovavili
2 hours ago
[-]
I guess you'll be stuck using something like Plan 9 then.
reply
ramon156
4 hours ago
[-]
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

reply
paperplaneflyr
10 hours ago
[-]
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?
reply
estimator7292
4 hours ago
[-]
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.

reply
RadiozRadioz
4 hours ago
[-]
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.

reply
pornel
5 hours ago
[-]
Growth of CUDA gave it a second chance.
reply