> I think this is an excellent example of why people get so excited about Rust. It can't do anything you can't do in C or C++, but it makes a whole bunch of things significantly easier and less stressful. Which makes maintenance easier, and in practice often leads to performance improvements because more ambitious designs can be attempted.

For most people Rust is just overkill, what I really want is secure subset of c++, enforced by compiler with hardened standard library(that is sanctioned by standard body, might be not 100% compatible with generic one, because it contains only a subset of functionality and some functions might work differently).

To me "C/C++, but secure" is equivalent to dreaming about sex on a beach. Sounds lovely as a concept, because you imagine the positives, not where the sand will get in.

It would be nice to keep the same language, same libraries, and codebases, and just somehow make them safe. But these were written for C++, not for a restrictive subset. You'll end up removing features that dependencies use (e.g. can you even ban non-smart pointers?). You'll add runtime checks to constructs that existing code assumed were free, and never needed to avoid (zero cost is a reason to use C++, otherwise a GC+JIT language can have runtime checks, but better). You will have to rewrite your code to clarify lifetimes, ownership, and remove constructs compiler can't analyze for safety.

You get many of the same pains that switching to Rust has, but none of Rust's features, and not even a fully-functional C++.

A subset of C++ cannot simultaneously be secure and useful, because to be secure a subset would need to ban pointers, references, iterators, moves and the ability to include code that is not part of this subset (for the last point modules might help, but they aren't here and they introduce their own ODR violations cases, so "safe" is a stretch even for them).

To retain usefulness, we need a superset of C++ that would include either a GC (at which point, why use C++), or lifetime-like annotations, and the need to actively migrate the ecosystem to it. At which point what you have is a rust-shaped language with an outdated compilation model, tons of pitfalls, an inexpressive type system, and a slightly better interop with C++.

Considering that such a language doesn't exist, that which features to remove and which to add will be source for endless discussions, I'd say that the move that isn't overkill is to use the language that actually exists today and delivers on these promises. Rust isn't overkill, despite 10-years of C++ experience I'm way more productive in Rust, be it while writing code, fetching dependencies, reviewing code, and of course all of this compounds during maintenance. You do need to invest 3 months to learn the language, and some more to write the occasional bindings, but they will be very quickly recovered by avoiding writing CMake (not even counting asan/valgrind debugging sessions).

> what I really want is secure subset of c++, enforced by compiler with hardened standard library(that is sanctioned by standard body, might be not 100% compatible with generic one, because it contains only a subset of functionality and some functions might work differently).

Problem with this is, that your code would use such subset, but what about libraries you use ? Then you would have confusion as to which libraries are safe to use in such new C++, would they work with the standard C++ ?

You would effectively have 2 languages inside of one. Remember all the C/C++ confusion and how compatibility to C has kept it back? That would lead to similar problems.

I'm not sure about this. Remember that most people (even most software developers) don't know C++ (or even C). And IMO (as someone who has tried to learn both) Rust is a lot easier to learn than C++

Careful now, you'll get accused of being in the Rust Hype Squad.

Snark aside, this is what Rust proponents like myself have been trying to say. Rust isn't some magical panacea to all of the problems we face in computing, but it does solve some frustrating and endemic problems outright while making others significantly more tractable. And that it manages to do so without sacrificing execution performance (though at a generally reasonable cost in compilation times) and keeping code complexity more manageable than equivalent C/C++ code is just icing on the cake.

What the language adds in complexity—in my experience at least—reduces the complexity of my own programs and makes it much simpler to write them and reason about them. There's definitely a learning curve as the language "wants" you to structure programs a certain way while it takes time to build up the intuition for doing so. But having done that, I've been able to apply those lessons to my projects in other languages to great success.