I still love C++ Builder, regardless of all Borland misteps that lead to where Embarcadero is today, it is the survivor of C++ RAD IDE tooling, Visual C++ never was as Visual as it name implies.
I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable.
C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization).
C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards.
C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc).
I simply don't understand what type of industrial use this type of theoretical abstraction building serves.
Using the metaprogramming features makes code bases extremly hard to modify and they don't actually protect from a category of runtime errors. I'm speaking from experience.
I would much rather have a codebase with a bit more boilerplate, a bit more unit tests and strong integration testing suite.
Better language? Well, now mix those with C libraries thst you need and make them generate code as efficient as C++ (I would assume people use C++ for a performance advantage of some kind in many scenarios).
"Many—especially historically minded—developers complain that modern C++ compilers take longer to compile. But this criticism is short‑sighted. You cannot compare C++ compile times with compilation in other languages, because the compiler is doing something entirely different."
> C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns.
I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software. Not impossible - there’s lots of examples - but unreasonably hard.
C++ is fundamentally unsafe, because that’s how the language works, and if you think otherwise, you don’t know C++. There are patterns and paradigms that people use to limit the risk (and the size of the impact crater), and that’s helpful, but usually very difficult to get right if you also want any of the benefits of using C++ in the first place.
Certain people will disagree, but I surmise that they haven’t actually tried any alternative. Instead they are high on the feeling of having finally grokked C++, which is no small feat, and I know because I’ve been there. But we have to stop making excuses. The range of problems where C++ is unequivocally the superior solution is getting smaller.
It is true that it will never be Rust-safe level bit there is ongoing work: stl library hardening is in for C++26, there are some temporaries dangling that has been removed (range for lofetime extension and forbid conversion snd binding to temporary), there is a form of implicit contracts on the way (this means that even regular code can be compiled wirh implicit bounds checking, including arrays) and there is sn ongoing effort to remove all forms of UB.
So I agree it has its quirks but if the defaults keep changing and improving it keeps evolving into a safer by default thing compared to before.
No, I do not mean into you must be super-skillfull anymore: I mean that with all of that in, things are much safer by default.
Things keep improving a bit slower than we would like (this is design by committee) but steadily.
> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means.
> But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because through evolution it has become a different language. Only those who understand the modern language constructs can use the new tools properly and unfold the potential of this generation of libraries.
Once you get to that point, you might as well create and learn a different language.
Despite all the critisism, C++ has been my favorite language for 20+ years. Nowadays I code 99% of the time in python and previously TypeScript, but all my personal for fun projects are in C++. I just enjoy coding in it so much more. I know I will get some heat for this, but I would love to live in an idealistic world where computers were still for hackers and it was all just about fun not profit. I was so inspired by the writings of Eric S. Raymond, I always hoped I would experience some of that. ~SIGH~. Maybe in my retirement.
It's okay to admit when C++ doesn't have a feature. std::variant is an approximation of sum type support. It's ergonomics are an absolute travesty as a result, any errors you get are going to be 5 pages of template gunk, and I'm sure that using it pervasively is terrible for compile times. It has been possible to construct a type safe unit library as demonstrated in the article for forever. I've never seen anyone use this ability in a production codebase, because a terrible library emulation of a feature is not a real feature.
The notion that just using the new fancy types automatically makes everything memory safe has to stop. std::expected contains either a value or an error. If you call .value() and you're wrong you get an exception. If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. Since there's no destructuring you have to call these methods btw, just don't make any mistakes with your preconditions! Regardless 90% of memory safety errors I see are temporal. Unless we completely ban references and iterators they will not be going anywhere. Using unique_ptr instead of new does not do anything when you insert into a map while holding a reference to an element.
Developers also have to be able to make their own things. We can't pretend that absolutely everything we will ever need is bundled up in some perfect library. To write a typesafe application you need to be able to create your own domain specific abstractions, which to me precludes them looking like this:
I think they should chuck the STL and start over. I left C++ for a while and spent a lot of time in C# and Swift. Going back to C++ is painful because the interfaces feel very non-uniform and cumbersome.
I also think that named parameters would go a long way toward improving the language.
Lastly, explore some way to make possible a breaking change with "old C++".
When I got into computing, it was a refuge from societal expectations. Now you cannot code in whatever programming language because of societal expectations to do it safe, do it with modern libraries, with the right build system etc.. just do what you like. Its OK. Have fun.
14 comments
[ 6.1 ms ] story [ 33.4 ms ] threadC++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization).
C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards.
C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc).
I simply don't understand what type of industrial use this type of theoretical abstraction building serves.
Using the metaprogramming features makes code bases extremly hard to modify and they don't actually protect from a category of runtime errors. I'm speaking from experience.
I would much rather have a codebase with a bit more boilerplate, a bit more unit tests and strong integration testing suite.
The longer I use C++ the more I'm convinced something like Orthodox C++ is the best method to approach the language https://bkaradzic.github.io/posts/orthodoxc++/
This keeps the code maintainable, and performant (with less effor than metaprogramming directed C++).
Note: the above is just an opinion, with a very strong YMMV flavour, coming from two decades in CAD, real time graphics and embedded development.
> C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns.
I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software. Not impossible - there’s lots of examples - but unreasonably hard.
C++ is fundamentally unsafe, because that’s how the language works, and if you think otherwise, you don’t know C++. There are patterns and paradigms that people use to limit the risk (and the size of the impact crater), and that’s helpful, but usually very difficult to get right if you also want any of the benefits of using C++ in the first place.
Certain people will disagree, but I surmise that they haven’t actually tried any alternative. Instead they are high on the feeling of having finally grokked C++, which is no small feat, and I know because I’ve been there. But we have to stop making excuses. The range of problems where C++ is unequivocally the superior solution is getting smaller.
So I agree it has its quirks but if the defaults keep changing and improving it keeps evolving into a safer by default thing compared to before.
No, I do not mean into you must be super-skillfull anymore: I mean that with all of that in, things are much safer by default.
Things keep improving a bit slower than we would like (this is design by committee) but steadily.
> But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because through evolution it has become a different language. Only those who understand the modern language constructs can use the new tools properly and unfold the potential of this generation of libraries.
Once you get to that point, you might as well create and learn a different language.
The notion that just using the new fancy types automatically makes everything memory safe has to stop. std::expected contains either a value or an error. If you call .value() and you're wrong you get an exception. If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. Since there's no destructuring you have to call these methods btw, just don't make any mistakes with your preconditions! Regardless 90% of memory safety errors I see are temporal. Unless we completely ban references and iterators they will not be going anywhere. Using unique_ptr instead of new does not do anything when you insert into a map while holding a reference to an element.
Developers also have to be able to make their own things. We can't pretend that absolutely everything we will ever need is bundled up in some perfect library. To write a typesafe application you need to be able to create your own domain specific abstractions, which to me precludes them looking like this:
It was slightly improved in C++26 under hardening:
https://en.cppreference.com/w/cpp/utility/expected/error.htm...
I also think that named parameters would go a long way toward improving the language.
Lastly, explore some way to make possible a breaking change with "old C++".