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?
C++ feels like an old lover who I think fondly of. We were together many years, until about C++20, through thick and thin. It was exhilarating - blazingly fast, perhaps irresponsibly so, but heck, the ride was wild. It taught me so many things, and shaped me into the programmer I am today. But we went our separate ways when its shortcomings became too large to bear, and its behavior - too often undefined - no longer excusable.
I keep up with it because I still have love for it, but I have to admit I am deeply concerned about many of the life choices it is making. I should have seen how problematic it was, because I knew its history, but I had hope that it could change, and it just looks like it never will.
I'm still rooting for C++, even though I am very happy with my new primary language, Rust. I hope it changes to the better, because I really want the best for it, but right now I'm just not seeing it. It keeps repeating old mistakes (e.g., more UB footguns with every new feature), without addressing any of the big flaws (insufficient tools for building robust software).
I sometimes still write C++, but I'm not excited about it the way I used to be. When I do write C++, it's because I have to. When given the choice, Rust is simply just a better choice for almost everything I do. Right now, I don't see a future for C++ and me.
The better analogy is C++ is the unstable person you date while thinking you can change them and make them better, only to look back years later and realize you should’ve walked away sooner.
I'm really torn about C++. I love C++ but there are things that I really don't like about it as well. It's a fantastic language in a lot of ways, but it carries around 40+ years of cruft, of things that you wouldn't do like that if you were inventing a programming language today.
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.
My (distant) recollection is that certain compilers didn't support them well at the time. We had to use the IBM C compiler for AIX back then, and it could have been that one.
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.
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.
I find Claude just terrible at writing C++ in comparison to how well it codes everything else I throw at it. It does bad choices, like it writes up new functions to do stuff that is already in the codebase, additionally seemingly can’t leverage the standard library, leans too much on the exact architecture of my computer vs what the codebase is meant to run, don’t seem to figure proper naming standards, keeps ignoring outputs from benchmarks or tooling and instead claim decisions on performance from thin air.
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.
> (...) that agents are currently pretty good at it if guided properly.
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?
> 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.
When it comes to generics/templates and expressivity, there are some arguably better languages around. But the range of having access to absolute low level control at the same time as highly abstract generic programming is virtually unmatched.
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.
Perfomance? Mostly agree, you need dynamic code generation to get much better than C++.
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).
I 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!
I love C++, in the C++11 days I even organized a local C++ User Group at my university, and I've used it for the last 20 years as my main language.
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.
This. Since Rust C++ has lost it's appeal for me. It used to have the good balance of performance/effort, but nowadays I wouldn't dare starting a new project using C++. Even LLMs are way better at coding in Rust.
I found the last part to be true for me as well, LLMs are pretty bad at writing C++ compared to Rust and Python. I believe their proficiency in the latter is due to an abundance of training data while their proficiency in the former is due to the language being "built" to reduce errors.
Not a troll question, because I am thinking of starting a fairly chunky project in Rust, potentially around 500k LOC. Are compile times really as bad as people suggest, in Rust? I'll be going agentic development, so it will be iterating a lot.
Honestly, coming from C++, Rust seems to compile very very fast. Those who complain about compile times usually come from Go, whose compiler, to be fair, barely needs to parse the code to call it a day. Or from interpreted languages where you don't have to wait at all. But in general, the Rust compiler is quite fast for what it does. If you have a 500kLoC project though, of course it is recommended to split it up into different crates (where it makes sense logically), to speed up even further.
I agree that C++11 was a big step. This was around the time I was working on a master's thesis, building a distributed optimization framework based around simulated annealing, using hand-optimized CUDA kernels on Nvidia CPUs. Writing CUDA code became a much nicer experience with C++11, and I didn't hate it.
However, it was still a bad choice for all the plumbing, caching, networking, job-management, etc that a useful framework needed, and I started using more and more Python. C++ was frustrating for those bits.
Eventually, after some important work on Numba[0], I was able to replace C++ completely, even for the CUDA kernels, and just write a subset of Python. It wasn't without it's (often quite esoteric) problems, but I was happy to throw out the last bits of C++ code. The thesis was praised and had some outside attention, but fizzled out in the years thereafter.
Still loving writing C++ and generally, it got much better over the years. User-Code (vs. library code) is quite easy to understand and it's easy to avoid pitfalls for the most part when using modern practices.
Main problem I see is that it has to move pretty slow. Reflection arriving finally now, but some more modern features might take an additional decade.
It feels however that around C++23/26, a lot of decade-long developings ( i.e.compile time stuff) are getting close to form a complete system without major limitations for the most part.
They also took notes regarding errors and templates, so the user experience also improved a lot (i.e. with concepts).
Yes I mostly enjoy it, but I don't do anything critical with it and I'm nowhere near expert level. I use the subset of it that makes sense to me. If I were doing something critical I'd want to use Ada, which I've played around with a little bit.
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'd like to put in a "no" after spending many years writing C++; my day job is in C# now.
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 only used it for bare-metal embedded and Linux user space where efficiency was important.
Some features are nice. Some arrived too late, like std::optional in C++17 [0] or std::expected in C++23 [1], and some features requires too deep knowledge of the language, like std::move unable to optimize for containers of structs without "noexcept" in their constructors. [2]
But honestly, the reason why I don't enjoy it is unrelated to the features added to each new standard. It's the build system. I just want to cross compile easily, add sanitizers to testing, and the minimal third party libraries I may need. I think I don't have to explain here how complicated it can get when you have to use CMake/Meson/Bazel, compared to other build systems.
When things get too complex for C, that's where C++ should be used... but I'd generally rather use something else instead. A lot of languages have been created to avoid using C++. Take your pick.
I never enjoyed programming in C++. I feel its (original) syntax and approach to OOP to be obnoxious. I never looked into C++11, though; I hope things improved. The first love was always for C; notwithstanding all its shortcomings, I feel at home writing C, and I would still enjoy doing so.
I first met C++ in 1992 and hated it. Still do. I'm mostly ok using any language, but C++ and scala are the two that I hate. Both for the same reason, the incredibly baroque overcomplexity.
I like coding in C++ a lot. I think it is great that it can both be a high level language an a low level one. One has control of the bits if one wants that but there are also a lot of goodies to make things happen automatically. I think RAII is the greatest invention in programming ever.
I can't claim to have ever liked it, sadly, as much as I like C. The language has a significant number of footguns (the FAQ is unbelievably expansive and would require superhuman effort to internalize).
But really it's the error messages. I remember them being awful in the early 90s, and they're still awful today. It is an inevitable comment from students who hadn't yet been exposed to it.
I'd greenfield in Rust over C++ every time today, especially with LLMs involved. If I'm going to have slow compiles, I might as well get as much proof of correctness from the compiler as I can.
I love C more than C++, but I still code in C++ occasionally. I try not to go beyond C++98 syntax (or C++2003). I hate templates, iterators and long namespaces. Basically I don't like STL, though I may use it. I use NULL for null pointers and I use pointers instead of references. I think this style was called "C with classes" back in the days. :-)
I really enjoyed writing C++. At least the C++ with for loops, calling functions and the sort. Not so much the c++ of template specifications. I recently saw [1] and the point of C++ building new things with the template mechanics really resonated with me. Features built that way stopped me from using the part of C++ I really liked.
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.)
Modern C++ is nice to use, except cases where stupid mistakes caused by its heritage can be made (like returning std::string_view to a temporary string).
The criticism is absolutely right on the money. However, you can choose to ignore the more complicated parts and use only the ones you know (well). That's what I'm mostly doing.
I've felt for at least the last two decades that C++ is trying to solve everyone's problems, no matter how obscure.
Recently I have started to learn C++. It feels nicer than C at first, while remaining in more C like. But moving to more C++ feature doesn't feel good. I heard many others use C++ just for some extra feature on top of C and leave many features out, like not writing classes. I like that way too.
I still don't understand the "feature creep" complaint
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++
There's a big difference between a function or class that you didn't know about (or has just been added to the standard library) vs a new language feature.
Python isn't immune from those either by the way (e.g. walrus operator, pattern matching) but nowhere near C++ level.
While I agree that the Python standard library contains a lot of stuff, I am surprised that you have never heard of the unittest module. Sure, pytest is a very popular replacement, but its documentation frequently refers back to unittest, and the unittest module is also one of the top hits if you search for "python testing".
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/
Yes, on side projects where I get to use concepts or modules, or even ranges.
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.
I recently got back into C++ and I've been really enjoying the new features in C++23. It's still a very imperfect language but it feels a lot more modern these days.
I stopped using C++ around the time when Boost libraries were a thing. It was fun to think a bit of how to do metaprogramming, but it quickly became apparent that this was not the right way to do things.
Modern dialects of C++, sure. There's a nice language in there, it just comes with everything else and the kitchen sink. The most horrific code I've ever had the misfortune of working on was also C++.
Yes, but I feel reticent nowadays in voicing out loud why exactly I like it (along with liking Rust). Because I don't want to give up my business ideas for free.
Whenever I write C++ that isn’t, like, pure algorithms I usually find myself wishing I had a nicer language where I could represent what I wanted in a clearer way.
The metaprogramming features of C++ are the killer feature. Only zig comptime comes close. But zig deliberately doesn't allow operator overloading, so high-performance array/tensor programming APIs aren't anywhere near as ergonomic. Since I work in high performance scientific computing, this is a major drawback.
FWIW I was a Rust contributor, pre v1. I don't see Rust as a competitor to C++, but a 'better c' - you can clearly see this by looking at where Rust adoption is highest.
C++ has a boilerplate problem but at least more recent versions have addressed the biggest pain points - 1000 line compiler dumps of of template instantiation errors are less of an issue.
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:
When I switched from C++ to C# many years ago because of a job, I felt a real ick. Not just because of garbage collection, I remember feeling repulsed by the fact that every class had a "ToString()" method! Bjarne says that the common denominator of all classes is the empty set! But also, an English word, made from letters! Yuck! Everyone knows that you should only ever overload operators because special characters are so much purer!
My C# days are now long gone as well, and I guess when I switched to JS/TS, I was so deep in the filth that I had just surrendered. I will say though, that looking back, I do feel like I was in a bit of a cult. I appreciate abstractions being free or near-free, but it feels like the language sort of wants you to engage in bike shedding.
I have a love-hate relationship with C++. I am currently working with C++23 professionally in a complex project, with python layer on-top.
C++11 and later turned the scale more towards enjoyment, but having less time for tinkering and deep diving makes me annoyed. It's not entirely the core language's fault, but since high performance is the name of the game for C++, every library seems to make twists and turns to not leave anything on the table, which increases the cognitive load when writing code, be it performance critical or not.
AI now alleviates that quite a bit.
I wish it was as concise as python, e.g. with the list comprehension. When I try to use the newfangled ranges algorithms to replace a (range-based) for loop, I roll it back in 90% of the cases because it neither is shorter nor more expressive.
Personally, I've never seen anyone write C++ codebases without boost. As you pointed out, the only practical way seems to be to constraint its feature complexity through meta programming.
Coming from the embedded C++ world where resources are scarce, C++ and its debugger ecosystem have been really nice. There were usually strong vendor provided SDKs and cross compilation toolchains available.
The issues I had with the language were mostly dependencies on vendors, not effectively being able to fix problems in SDKs, and as you also mentioned the footguns.
Lots of frustrations came from codestyle, branch conventions and type conventions we tried to encode into templates, which new team members had to learn before they could write any production code. So from a team perspective a lot of productivity came from reproducible build pipelines and setups. Having one team member on Windows and the other on macOS or Linux was as painful as it can get, especially with getting gcc's ecosystem to work properly. So you were also really dependent on Docker cross architecture images. And setting those up just for the sake of compilation was also unnecessary overhead.
These days I've migrated towards Go for pretty much all tasks I can think of, mostly for the tight integration with the C ABI ecosystem and tinygo and the easy possibility to cross compile into fat binaries.
What I miss though is a "real IDE" like the old Visual Studio, or geany or whatever. Most IDEs are not symbol based anymore, which makes them really painful to use in terms of what I expect an IDE to offer to be able to call itself an IDE. But maybe this is just my C++ heart bleeding all over the place because I miss good and typed API documentation examples that I can explore through clicking rather than having to google every function all the time.
Everything added to C++ since 1989 has mostly made it worse. Those inclined to disagree may want to consider how easily they drink someone else's kool-aid.
Back then, "the Stroustrup book" was narrower and no thicker than the K&R book. Average programmers could hold its entire conceptual content in their head, just like plain/good old C. The language itself had a constrained vision of what it did better. It had yet to become an inscrutable lapdog that made everything worse by trying (and righteously failing) to please every last someone. Those halcyon days are long, long gone. :-)
when I didn't know better (i.e., didn't know many other languages), back in 96 to maybe 2002 or so, I tremendously enjoyed C++. I felt so powerful. It was hard to get things right and fast following the literature at the time, but hey, low-level, power, yay!
Then I took a turn and learnt LISP, ML, and a whole potpourri of functional languages. Things were so easy to express in comparison to looking at _all_ the details _all_ the time. I dropped my C++ for quite a while.
Fast forward a decade, and I spent about a decade writing C++11 code. Then C++17. I didn't particularly enjoy it, but it got the job done. In the environment at the time, alternatives were not accepted, so I obliged.
Now I just see loaded and unsecured footguns everywhere when I look at C++. Note that I'm still paid to write C++, but after learning to trust smart compilers in semantically proper languages, learned about data oriented programming, learned about all the bad from the pointer-laden object-oriented style, about the problems of (thread) synchronization C++ style vs. message passing between programs (CSP), ... I grew to despise it.
Frankly, nowadays, I'd rather write in Ada, drop all the "smart" constructs whose smell reek through the whole code-base, and all the implied semantics of various interfaces which are not described on language-level but (maybe, hopefully) in the comments ... the everything-and-the-kitchen-sink approach of C++ bites us regularly, but still, the environment has a hard time accepting non-C++ code.
yep, i actually liked stl, iterators with auto also seem like a godsend now compared to how verbose they used to be. the biggest pain point for me was keeping track of all the required ctors and operator overloading. admittedly i used it back when all pointers were just *, once i discovered a single line of python could do what it took 10-100 lines of C++ to achieve i switched. so its been a looooong time since i programmed in C++, but i did like it overall.
C++ feels like an old lover who I think fondly of. We were together many years, until about C++20, through thick and thin. It was exhilarating - blazingly fast, perhaps irresponsibly so, but heck, the ride was wild. It taught me so many things, and shaped me into the programmer I am today. But we went our separate ways when its shortcomings became too large to bear, and its behavior - too often undefined - no longer excusable.
I keep up with it because I still have love for it, but I have to admit I am deeply concerned about many of the life choices it is making. I should have seen how problematic it was, because I knew its history, but I had hope that it could change, and it just looks like it never will.
I'm still rooting for C++, even though I am very happy with my new primary language, Rust. I hope it changes to the better, because I really want the best for it, but right now I'm just not seeing it. It keeps repeating old mistakes (e.g., more UB footguns with every new feature), without addressing any of the big flaws (insufficient tools for building robust software).
I sometimes still write C++, but I'm not excited about it the way I used to be. When I do write C++, it's because I have to. When given the choice, Rust is simply just a better choice for almost everything I do. Right now, I don't see a future for C++ and me.
But damn was it a wild ride
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.
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.
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?
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.
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.
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.
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!
I 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!
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.
However, it was still a bad choice for all the plumbing, caching, networking, job-management, etc that a useful framework needed, and I started using more and more Python. C++ was frustrating for those bits.
Eventually, after some important work on Numba[0], I was able to replace C++ completely, even for the CUDA kernels, and just write a subset of Python. It wasn't without it's (often quite esoteric) problems, but I was happy to throw out the last bits of C++ code. The thesis was praised and had some outside attention, but fizzled out in the years thereafter.
0: https://numba.pydata.org/
Main problem I see is that it has to move pretty slow. Reflection arriving finally now, but some more modern features might take an additional decade.
It feels however that around C++23/26, a lot of decade-long developings ( i.e.compile time stuff) are getting close to form a complete system without major limitations for the most part.
They also took notes regarding errors and templates, so the user experience also improved a lot (i.e. with concepts).
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++.
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.
The language has left a lot of people behind, and that's for the best. It's a different beast now
One I enjoy programming. Another I dread.
"C++, but codebase is 20 years old"
"C++, but we ban or dont like most of C++ features"
"C++, but everything must be a template"
"C++, but codebase is completely new and we only use the new features"
"C++, but its the stl codebase"
"C++, but you are reading Stroustrup's book"
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++...
Some features are nice. Some arrived too late, like std::optional in C++17 [0] or std::expected in C++23 [1], and some features requires too deep knowledge of the language, like std::move unable to optimize for containers of structs without "noexcept" in their constructors. [2]
But honestly, the reason why I don't enjoy it is unrelated to the features added to each new standard. It's the build system. I just want to cross compile easily, add sanitizers to testing, and the minimal third party libraries I may need. I think I don't have to explain here how complicated it can get when you have to use CMake/Meson/Bazel, compared to other build systems.
[0] https://en.cppreference.com/cpp/utility/optional
[1] https://en.cppreference.com/cpp/utility/expected
[2] https://0xghost.dev/blog/std-move-deep-dive/
When things get too complex for C, that's where C++ should be used... but I'd generally rather use something else instead. A lot of languages have been created to avoid using C++. Take your pick.
Classes and smart pointers make some things so much easier that would take an age in C
But really it's the error messages. I remember them being awful in the early 90s, and they're still awful today. It is an inevitable comment from students who hadn't yet been exposed to it.
I'd greenfield in Rust over C++ every time today, especially with LLMs involved. If I'm going to have slow compiles, I might as well get as much proof of correctness from the compiler as I can.
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
I've felt for at least the last two decades that C++ is trying to solve everyone's problems, no matter how obscure.
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++
Python isn't immune from those either by the way (e.g. walrus operator, pattern matching) but nowhere near C++ level.
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
do you still enjoy speaking english?
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.
No, I migrated away from it in 2014 and it was one of the better decisions I made in my business. Productivity and quality went up.
FWIW I was a Rust contributor, pre v1. I don't see Rust as a competitor to C++, but a 'better c' - you can clearly see this by looking at where Rust adoption is highest.
C++ has a boilerplate problem but at least more recent versions have addressed the biggest pain points - 1000 line compiler dumps of of template instantiation errors are less of an issue.
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++
I know this doesn't add much to the conversation but, well.
My C# days are now long gone as well, and I guess when I switched to JS/TS, I was so deep in the filth that I had just surrendered. I will say though, that looking back, I do feel like I was in a bit of a cult. I appreciate abstractions being free or near-free, but it feels like the language sort of wants you to engage in bike shedding.
C++11 and later turned the scale more towards enjoyment, but having less time for tinkering and deep diving makes me annoyed. It's not entirely the core language's fault, but since high performance is the name of the game for C++, every library seems to make twists and turns to not leave anything on the table, which increases the cognitive load when writing code, be it performance critical or not. AI now alleviates that quite a bit.
I wish it was as concise as python, e.g. with the list comprehension. When I try to use the newfangled ranges algorithms to replace a (range-based) for loop, I roll it back in 90% of the cases because it neither is shorter nor more expressive.
Have you used Pyomo?
Coming from the embedded C++ world where resources are scarce, C++ and its debugger ecosystem have been really nice. There were usually strong vendor provided SDKs and cross compilation toolchains available.
The issues I had with the language were mostly dependencies on vendors, not effectively being able to fix problems in SDKs, and as you also mentioned the footguns.
Lots of frustrations came from codestyle, branch conventions and type conventions we tried to encode into templates, which new team members had to learn before they could write any production code. So from a team perspective a lot of productivity came from reproducible build pipelines and setups. Having one team member on Windows and the other on macOS or Linux was as painful as it can get, especially with getting gcc's ecosystem to work properly. So you were also really dependent on Docker cross architecture images. And setting those up just for the sake of compilation was also unnecessary overhead.
These days I've migrated towards Go for pretty much all tasks I can think of, mostly for the tight integration with the C ABI ecosystem and tinygo and the easy possibility to cross compile into fat binaries.
What I miss though is a "real IDE" like the old Visual Studio, or geany or whatever. Most IDEs are not symbol based anymore, which makes them really painful to use in terms of what I expect an IDE to offer to be able to call itself an IDE. But maybe this is just my C++ heart bleeding all over the place because I miss good and typed API documentation examples that I can explore through clicking rather than having to google every function all the time.
Back then, "the Stroustrup book" was narrower and no thicker than the K&R book. Average programmers could hold its entire conceptual content in their head, just like plain/good old C. The language itself had a constrained vision of what it did better. It had yet to become an inscrutable lapdog that made everything worse by trying (and righteously failing) to please every last someone. Those halcyon days are long, long gone. :-)
Then I took a turn and learnt LISP, ML, and a whole potpourri of functional languages. Things were so easy to express in comparison to looking at _all_ the details _all_ the time. I dropped my C++ for quite a while.
Fast forward a decade, and I spent about a decade writing C++11 code. Then C++17. I didn't particularly enjoy it, but it got the job done. In the environment at the time, alternatives were not accepted, so I obliged.
Now I just see loaded and unsecured footguns everywhere when I look at C++. Note that I'm still paid to write C++, but after learning to trust smart compilers in semantically proper languages, learned about data oriented programming, learned about all the bad from the pointer-laden object-oriented style, about the problems of (thread) synchronization C++ style vs. message passing between programs (CSP), ... I grew to despise it.
Frankly, nowadays, I'd rather write in Ada, drop all the "smart" constructs whose smell reek through the whole code-base, and all the implied semantics of various interfaces which are not described on language-level but (maybe, hopefully) in the comments ... the everything-and-the-kitchen-sink approach of C++ bites us regularly, but still, the environment has a hard time accepting non-C++ code.