C++ probably needs an "unsafe" keyword like Rust to isolate the non-"good parts". A few hundred compiler flags could be used to distinguish the good and non-good parts. I don't think that 5 years is enough to know all things C++; it's like a black hole in the sense that it adds features faster than you can learn how all the different parts could interact - even if you dedicate your whole life to it. Maintaining old C++ codebases will employ a lot of old developers for many many years. Your employer should not expect you to understand an old code base if you are a new developer. This would even be counter-productive since it wastes your brain power and their money.

What modern C++ really needs is a rebranding. Something like "C22"/"CX"/"Z" to distinguish itself from old C++. Together with a guide on what the safe features and "unsafe"/deprecated features are the developers could get new certificates to prove that they are up to date. Companies/management could easily require that the new C++ is used and developers are actually capable. (This organizational issue is IMHO the most important part.)

It already kind of has it, it just requires a bit more of love and fewer false positives.

https://docs.microsoft.com/en-us/cpp/code-quality/using-the-...

it is called "new" and "delete"

but yeah, there is more to that and I doubt C++ can be fully unsafe unless you set references and pointers (they can be invalidated) probably many other things as unsafe. c++ is unsafe by design

Ha. People have been making exactly this complaint for as long as C++ has been around. Meanwhile the language just keeps rolling on, picking up new features like some demented Katamari Damacy character.

It’s a puzzle. One can only conclude that secretly C++ programmers like all the new feature whilst complaining bitterly about them in public.

Us c++ programmers have yet to find a paradigm we didn't like.

I think it's because C++ serves a wide set of users across a wide set of paradigms. I doubt every C++ dev is enthusiastically using every feature.

There's certainly quite a lot to the language. There are really two audiences for C++, those writing generic libraries, and those using them.

If you're in the former group you'll be delving into all the template nitty gritty. If you're in the latter group you'll rarely need them (I think our 200k+ LOC C++ codebase uses std::enable_if three times).

I still like the language though. There's no obligation on any C++ dev to use all the new features.

Personally, I find Rust's syntax to be quite ugly compared to C++'s; horses for courses I suppose.

Let's see what happens to Rust in another 10-15 years. I suspect there will be people talking about it having too many features which make it hard to read and maintain and that they look forward to migrating to the new and simple "Mend" programming language.

If you can use Rust instead of C++, look at it as a privilege: there are very important code bases that need to be maintained in C++, and modernizing the code base is still easier (and easier to automate) then moving to a new language.

You are very right. I have programmed for a long time in C++98 and "Modern C++" does feel somewhat alien to me. I don't see the actual need for some features (eg. range for is just syntactic sugar) while threading etc. are very welcome. The combinatorial explosion arising from mixing and matching all the available features really makes code using advanced techniques nearly opaque to "ordinary" programmers. So unless needed otherwise we have to confine ourselves to a "familiar subset" of the language; very few people can have mastery of the full language.

The truth is that most folks writing c++ are spending a ton of time debugging their language knowledge or sticking to what they know.

The language is almost totally unprincipled in my opinion so you just have to know the minutiae to reason about and work with novel constructions.

In the hands of an expert, it's an awesome tool. To me, it's a miserable chore.

> C++ is becoming a real mess of features

> I am now looking forward to learning Rust

Prepare yourself. I personally think one of the major downsides to learning Rust is how quickly the language is moving.

I first started looking into Rust in ~2015, but it seems most hobby projects from that time won't even compile today.

It feels like there are non-breaking changes to the language almost weekly. I still cannot figure out if I should be using nightly rust, stable rust, or switching back and forth depending on the project.

Overall I think Rust is doing a lot of great things, but I'm not sure it is handling the "mess of features" aspect of programming languages particularly well.

Thanks for pointing this out, as well as a few other sibling posters. That makes sense, though I hope that, as Rust doesn't seem too afraid of deprecating features, it will keep the language a bit leaner in the long run, when it will have stabilized even more. Of course, that comes at a cost, if the language isn't 100% forward-compatible.

It's almost like... wait for it... C and C++ are not the same programming language?

Nah, couldn't be! It's just C++'s fault, surely!

This applies to any language that has been long enough though.

Do you think anyone dropped into a foreign code base of Java 15, C# 9, PHP 8, Python 3.7, C2X will be able to understand all of it?

I'm looking forward to learning Zig as it approaches 1.0.

Me too, but I see Zig as a C alternative and Rust as a C++ alternative. I am not competent enough to judge either way on this. I am currently back to C++ for a project that is written in C++. If it were C, I would try to write small pieces in Zig. I guess Rust could be used, but I am nervous about the scope of work I would be taking on - learning Rust, getting familiar with a C++ codebase, etc.

This is a common refrain, but I'm not sure how accurate it is. I work with a bunch of C folks who never liked C++, and now write Rust. It just depends.

Rust is always on my list. I am a happy user that is grateful that Zig and Rust both have great stewards!