Is C++ Doomed?

To me, bigger flaws with C++ are that it's too big. The language is bloated with multiple features that accomplish similar things, but each with their own odd corner cases and interference. Anytime there's an issue from a language component, the solution is to tack another language component on top of things. See for example the progression of Macros -> Classes -> Templates -> Constexpr -> Concepts. Each tried to fix flaws in the previous design, but each introduction made the language more complicated, not less.

> But exceptions come at a performance cost.

I mean it's slow to throw, but non-throwing code paths are hardly affected. Typical implementations store the exception unwinding stuff off to the side, so the only cost is binary size.

> That means you need to write code that wraps every possible resource in RAII logic.

Consider using scope guards. You can write them directly in your code, without a separate class per resource.

    int* ptr = malloc(...);
    auto guard = defer([&]{ free(ptr); });

By that I mean stop using every feature and detail because it's there.

C++ can be used like a much better C (smart pointers, references, const-correctness, generics via templates) and most of the complications can be ignored that way.

Premature optimisation is another big factor. If there's no measurable performance bottleneck, things like move-semantics don't even matter in practise for example.

If you need full raw pointers with aliasing mutable pointers, the fact that fn drop() takes a &mut T is a problem that can only currently be worked around with fugly hacks, like nesting your data type in another pointless structure, not to mention the giant pile of ambiguous UB that you risk whenever pointers and references interact that could so easily be avoided if Rust would just implement an -fno-strict-aliasing switch, but the devs refuse on what appears to be ideological grounds. The result is that for unsafe Rust, you get about the safety level of C much of the time, because RAII and many language facilities are not safe to use. Unsafe Rust is currently so dangerous that I feel much safer reaching for C++ for some of it. Mutable reference uniqueness, I think, should be enforced by the borrow checker and NOT by pain of inescapable possible undefined behavior at the assembler level.

Now for C++.

C++ is lacking a LOT of useful safety features that Rust comes with baked in, such as Mutexes owning their data, the borrow checker, a good, fast atomic reference counting type, and things that translate to more safety indirectly, like algebraic enums, assignable and movable arrays, tuples built into the language, etc. Generics in Rust, however, are significantly more painful to write due to the lack of duck typing. Perhaps the Rust devs felt that duck typing was too "dangerous" for templates, but because they're statically evaluated, these issues almost never materialize, and so in practice duck typed templates are almost always superior to Rust's generics.

C++ is definitely more mature and pragmatic as a language, but Rust is probably better for systems programming overall, at least if they fix their goddamn unsafe UB stuff.

As for move semantics, that book isn't for "what you MUST do to keep things semi-safe!" though it contains some stuff to that effect. It's more about optimization and tricks from what I can see. Move semantics take a little while to wrap your head around, but once you know the basics of C++'s move semantics, you can pretty much figure out what's going to happen by looking at a class' definition briefly.

TFA: "That is, of course, until you realise the design philosophy that is being followed. They literally just implement whatever the current fad in programming is."

It costs binary size for unwinding tables, and in some cases it is an optimization barrier.