Is C++ Doomed?

No, just as Betteridge's Law would lead you to suppose.

This really boils down to "creating your own custom data object that plays nice in all scenarios is too hard". (Or, more cynically, too hard for the author - some of us don't find it particularly hard.) Does that mean C++ is doomed? No, it just means that not all C++ developers are going to create objects with full RAII initialization semantics and full rule-of-five acts-like-an-elementary-data-type behavior.

And that's fine! Not every object needs that. And if your object doesn't need that, you don't have to put it in.

The problem, of course, comes when you have an object that needs all that, and you don't know how to do it. But that's kind of true for every feature you don't know how to use, in every language. So are all languages doomed? No.

Now, you could make a case that creating objects that have all those behaviors is the ideal in C++, and it's too hard to achieve that ideal. But hyperventilating about how that makes C++ doomed doesn't do anything to actually make that case.

Something that I have learned is that we build abstractions to hide complexity. In so far as abstractions are not leaky and are fast, all is good. The moment you have a bug, or the moment you want to analyze performance, abstractions absolutely puke their f'ing guts at you and all that smart stuff someone thought no one would ever see spills all over the floor and it's a flat-out mess. C++'s pervasive unsafety and pervasive obsession with performance are the worst kind of witch's brew for plunging you straight into a hell of unimaginable depths at the slightest mistake.

In particular, undefined behavior is so pernicious that it exposes literally everything about the machine and the entire program at once--its memory layout, compiler optimizations, and whatever else you weren't supposed to see. You are staring at a whole pile of hot garbage. There are literally no constraints on what the entire system is required to provide to you as aid to debug the problem. Undefined behavior literally gives no meaning to the entire execution of the program since its start, no matter where or when the undefined behavior occurred. There is no "before" UB and "after" UB--the entire execution is invalid. You are in a parallel universe that is not required to make sense.

Both C++ and Rust are rather complex.

But in Rust the negative effects of the complexity are mostly contained by the compiler (i.e. if you get it wrong you get a compiler error).

In C++ it on the other side can easily lead to UB and in turn to potential security vulnerabilities.

So IMHO today there are _very_ few cases where C++ is still the appropriate choice.

Just to be clear I'm not saying rust did replace C++, but there is a wide variety of languages which are a better choice for many use-cases which once where filled by C++. Rust just further reduces use-cases where I would say C++ is appropriate.

But it's anyway not Doomed as there are just way to many existing projects. Not just legacy projects, but existing still maintained for many years projects.

Low level linalg... implementing solvers using openmp and CUDA

Having followed SerenityOS for some weeks, I now believe C++ is doing fine.

Also, that cookie pop-up on WordPress gave me cancer.