Ask HN: Do you still enjoy coding in C++?
In the recent years C++ received a lot of backlash due to its complexity and (perceived) feature creep. However, since C++11 I really enjoyed writing C++ with its strict type system (including const), range-based for loops, smart pointers, and how much you can do with templates. On the other hand, I know that it can be very tricky to write, for instance, a correct iterator, to get handling of rvalue references right, or to read error messages that involve templates.
So, do you enjoy or dislike writing C++ source code and why?
82 comments
[ 3.2 ms ] story [ 47.7 ms ] threadI acknowledge that C++ is a bad language in a lot of ways, but it's a bad language which I know really well, and it fits with how I think about code. And it lets me effortlessly do "clever" things with how memory is managed to avoid unnecessary allocations etc. I've already learned most of its idiosyncrasies, handling rvalue references/move semantics, how to go about implementing contracts like iterators and containers, etc.
I also like writing Rust, and I like how Rust makes sure I don't make mistakes. I think Rust is a better language in many ways and I think it's the future of low-level programming (and I think it's wild that it took so many decades to get a proper competitor to C++!). But I also like how C++ doesn't care and lets me do whatever I want without acting as a nanny. I would never ever dare to write a publicly exposed web server in C++, but a game? Sure!
C++ is by far the most powerful language around. And this is for the best and (often) also the worst.
In term of generic programming, control on hardware, capacity of abstraction and more generally expressivity: Nothing, even today, come even close to C++.
It is a language full of foot guns and it has its fair share of legacy problems.
But if you learn to avoid it (throught experience and pain). You can reach a productivity and a level of performance in C++ which is very difficult to beat with anything else, including Rust.
Ironically, I find it particularly true in the age of A.I.
Because the amount of C++ around is so tremendous, that agents are currently pretty good at it if guided properly.
But the footguns are also impressive and formidable. And one of the unique powers of the language is that it allows the user to build constructs that improve the power of those footguns by several orders of magnitude. And teams can happily build footgun force multipliers without individually recognizing what they are working on.
I still write lots of C++, and the overall reason has more to do with the ecosystem (which is unmatched for what I do) than the language itself. I like it, but learning other languages made me yearn for features that C++ won't likely get before I retire a few decades from now (curse you, Walter Bright, for your awesome ideas! ;) ). In some ways, I feel about C++ like a child who saw ads of awesome toys, but they aren't available for purchase.
With all other languages I guess because things are more standard it can probably more easily guess than having to follow specific project guidelines, but my experience with C++ with it is not good at all.
It is amazing at python, Rust and pretty all web stuff I tried. But with C++ it requires a ton of guiding and I need to correct all generated lines all the time it seems.
I dont use Claude. I use DeepSeek and it is very capable. I have found Gemini and Mistral4 equally capable.
One thing I realised however is that Agents adapts to the existing code style:
- Give them a modern, polish C++ codebase and they will produce clean modern C++ - Give them a legacy codebase and they will produce a festival of raw pointer spaghetti and loose themselves. It seems that evem for A.I there is 10^6 variations of C++.
- Force them to use span and string_view and 90% of boundaries problem and lifetime go away. It seems to ease their reasoning.
- A single line in the AGENTS.md is enough for them to properly use fully sanitizers in their test. - They are pretty good at leveraging defensive programming if asked to.
Few negative points: - They are still pretty bad at reasoning about memory hierarchy and memory allocation. But thats hardly surprising, very few codebase do it properly. - You need to explicitly list your dependencies and build system or it's a festival of reimplementation. I have beem pretty successful with Nix so far.
I think I partially agree with that.
If you create your type system and templates first, agents can be pretty helpful filling in the blanks or "wiring"/integrating an external API into your own type system.
The issue is that I always have to force agents to read that type system before I can prompt them with a task like this, and always have to prompt them to not touch/extend/modify that type system and to use existing codestyles etc.
So I guess I haven't figured out a good type system discovery in my workflows yet. Would be interesting to see how you work with agents here.
Got an open sourced repo by chance where the structure worked out well?
I have an AGENTS.md that I bring around in every repo.
Few things I found:
- On new project is that it is much more efficient to point the agent on an old, existing project and simply say "Copy the code style" than to try to document everything in a markdown file.
- Explicit listing of both headers and implementation in CMake target seems to help for dependency resolution.
- A simple "Analyze this codebase" on a folder helps a lot for context prefilling on complex type system. I have a compiler where the entire language grammar is defined as C++ types with mutual relations. DeepSeek is completely capable to understand it and debug grammar mistakes in a blink of an eye.
Productivity? Bwahahaha. This is language where 50% of code cannot even be debugged (like, for real. Nothing that executes at compile time is debuggable). Most crazy features are usually passed over with "normal users should simply use well written library and so this complexity does not concern them", then the normal user gets error, sees "decltype(auto)" or some sfinae monster, and is taken by ambulance (since last year, to chatgpt).
C++ is terrible for productivity.
Debugging constexpr is trivial with static_assert. In addition, most UBs are entirely eliminated at compile time which is excellent for testing.
> then the normal user gets error, sees "decltype(auto)" or some sfinae monster
Thats a non-issue in the age of Agents. They can reason about that very well. This kind of problem disappeared entirely.
Additionally, I would say that if you are still using SFINAE post C++20, the problem is you and not C++.
Also, if you find debugging requires clauses, sfinae clauses or expressions using static_assert trivial, please share your techniques!
One I enjoy programming. Another I dread.
I'm beginning to believe that some of the Rust evangelists are there just because they'd rather write code in anything but <some dialects of> C++...
However, I stopped writing C++ once I switched to Rust. I assume I would still enjoy writing C++, as long as I can avoid a lot of the templating features. (I might have a different opinion if I worked on different kinds of C++ projects, eg more people, more library oriented, etc.)
[1] https://www.youtube.com/watch?v=DZTkT1Cq_aY
Languages like C++, Scala, Haskell, is where I get the most fun coding, unfortunately the question can be reformulated as "Do you still enjoy coding?", as we get pushed to program into natural languages instead.
The templating system is more powerful than any other language I have significant experience with, but that also lets people write incomprehensible systems. And the compile times always have been really long.
I think the lurking question is about Rust. I've read a book about it and it has some attractions but also what I think are some poor decisions. I suppose I'll have to use it for something sometime. C++ is sort of like Perl, it seems to me. A lot of what seems like bloat is actually affordances, so the thing you want is often surprisingly close at hand. Some things of course are awful.
I wouldn't call C++ a good language but it does most of the things. Enjoyment doesn't always mean productivity anyway. I enjoy using Forth but that's almost like enjoying riding a unicycle. I wouldn't do anything substantial with Forth except for recreation. I do feel fairly productive in C++.
I haven't written C++ professionally for many years at this point, and my memories of using it professionally (pre C++ 11) are not happy ones: having to agree on a strict subset of the language that we were allowed to use, which avoided features that any of the compilers didn't support well, or that my teammates didn't like. Sadly back then the list of forbidden features included templates and namespaces.
But using C++ on personal projects nowadays, and being able to choose which bits of the language to use - and which to avoid - is much more enjoyable. And honestly, the language did get a lot better from C++ 11 onwards.
WinUI3 is awful for unrelated reasons. It's even a pain to use from C#, which is the language it (and the WinRT APIs) were designed to be the primary use case with. And of course C# namespaces work fine.
Newer Windows APIs are annoying to work with from C++, which is Microsoft's fault but signals something about direction.
If you have specific pitfalls to share, do so, otherwise what’s the point of commenting?
At the time of c++11 I did not write c++ at all, so I’m not familiar with the growing pains of namespaces. It makes sense.
Today, I find it quite nice and elegant.
I still appreciate its many merits but since a bit more than a year I migrated to Rust and I find it very difficult to look back, except for maintaining my previous C++ projects.
Surprisingly, it's not Rust's memory safety features that I miss the most when turning back to C++. It's mostly the absence of algebraic data types and pattern matching, and the split between compile-time and runtime polymorphism, i.e. concepts vs virtual classes, where in Rust you just have traits and use them for everything. On top of that the tooling and the ecosystem are just amazing.
There's a proposal for pattern matching sitting there under the committee's desk for some years now. With the mess that the standard committee is going through I really doubt they will be able to ship pattern matching for C++29 or even later. Too little too late.
So to answer the question, yes, I still appreciate the merits of C++ but I don't enjoy writing it as much as I have in the past.
In the decade prior to the release of the first version of C++ my company bought me a Lisp Machine, and programming was so much fun.
C++ was gnarly, and I put a lot of effort into making C++ easier for our new hires out of college to use (I wrote a C++ GUI library for them to use that evolved into my personal code for my two “Portable C++ GUI” books for McGraw-Hill). I ended up writing 5 C++ books, and using the language was fantastic for my career, but:
I never really liked C++
python just introduced built-in sentinel, and only comment on an explainer video brought up that it's nothing new and is just a rename of unittest.mock.sentinel
who even knew there's unittest module? who even knew there's unittest.mock? definitely not me
because it doesn't matter - you use what you need and learn what you encounter. Same thing with C++
It has also been in there since Python 2.1, as far as I can tell [1], though the mock module is somewhat newer [2], but still quite old at this point. In all that time, have you never skimmed through the list of modules in the standard library? I'd recommend doing so once in a while, since a lot of the stuff in there is quite useful: https://docs.python.org/3/library/
[1] https://docs.python.org/2/library/unittest.html [2] https://docs.python.org/3/library/unittest.mock.html