[User3456335]

I've yet to see a valid scenario where C++ is superior to Rust, Python and Go.

Use Python. If you need concurrency, then use Go. If you need even more performance, use Rust (using unsafe Rust only for the parts that need it). For the highest performance stuff, maybe consider C for critical parts only.

C++ is not safe. It's a minefield of things that compile but are memory management mistakes. And then you're like "Look, I have a map of the minefield. If we just make sure we don't step on any mines, we are completely fine."

[klodolph]

I can think of a few scenarios for C++ off-hand. Most of them involve integrating with libraries or frameworks that are written in C++, running on platforms that have good C++ toolchains, or working with verification systems that can process certain C++ or C subsets.

[User3456335]

Yes, but all of these are essentially all because the existing code is already based on C(++). We should be able to move to Rust sooner than people think.

[klodolph]

Should ≠ will.

We still have Fortran and Cobol. It’s easy to imagine that Rust will replace C++ Real Soon Now, because you just have to imagine that all of the legacy code disappears, and Rust gets all the tooling support that C++ has.

[tialaramex]

> "Look, I have a map of the minefield".

This doesn't exist. WG21 (the C++ language committee) has considered the idea of writing an appendix with such a map - a list of the UB (Undefined Behaviour) and IFNDR (Ill-formed, No Diagnostic Required) clauses in the language but this work has yet to be undertaken and I see no reason to expect it in C++ 26.

I have been in plenty of disagreements with C++ proponents here and on r/cpp where it's clear that there isn't even agreement on what the standard means today in respect of these problems, if you guess one way and the people who implemented your compiler judged differently then your program may have defects you didn't even realise were possible.

[spacechild1]

> I've yet to see a valid scenario where C++ is superior to Rust, Python and Go.

What? Python and Go are used in entirely different domains. Not everything is a web backend!

Today C++ is used mainly for performance critical applications: HPC, realtime audio, video editors, game engines, web browsers, operating systems, etc. In these fields, Rust would be pretty much the only practical alternative, but it still needs to catch up with the massive and mature(!) C++ ecosystem. Things like Eigen cannot even be implemented efficiently in Rust because its metaprogramming features are still too limited.

[Scubabear68]

It’s not just the lack of safety. It is all the insane gaggle of features, from the multipage errors from template errors to “diamond inheritance” to experts yelling at each other over temporary lifetimes.

The language has always been a dumpster fire. The best thing I can say about it is that is spurred development of many other languages to get away from it.

[jvanderbot]

isolated experiments and a rank-choice ordering of languages is not a realistic picture of the industry.

In robotics, everything is C++. There's plenty of python being used to train networks, but that's not because of performance, safety, or anything, it's mostly born out of the existence of key libraries being in Py. But those libs are just wrappers on C (cuda, essentially).

Essentially the whole of every robot is C and C++. Essentially the whole of every airplane is C, C++, and a scattering of memory safe languages in isolated corners. The ATC system, the rail system, most industrial processes are C or PLC, or maybe C / PLC generated by matlab/labview. Automobiles, basically everything with a microcontroller. It's all C.

Our scientific computing? fortran. Nodejs? A bunch of C++.

What's my point? It's that for any new project or extension of above projects, the existing language is a superior choice (as viewed by managers, business leaders, CTOs, or rushed grad students trying to get quick results, etc), simply because the legacy provides a quicker startup. This is the "reality" - we have had better options essentially forever, and I feel we are effectively stuck with C/C++ forever. It's just that we'll see less and less of it if the new communities are diligent about extending the existing ones. Otherwise, it will never make sense to start clean, not on a mass production level, or at least not this decade or likely next.

C++ is a bad choice, and it is the choice. it can be both a prevalent "obvious" choice, and also a bad one. The existence of a better language does not shift reality on its own. You need targeted investment for development of a replacement ecosystem built around that better option. Whether that is Rust, or safe C++, or C+borrow checking, or Dada, or the language of the minute. We as a community cannot keep screaming about how nice a new idea is without building out the ecosystem to make it the obvious idea.

[lostmsu]

Don't use Python. You will produce unmaintainable code that will have to be thrown away in 5 years because it is impossible to refactor.

[User3456335]

Interesting. Are you sure it's the language and not the programming style? There doesn't seem to be a reason to prevent you from writing maintainable Python code.

[lostmsu]

Reasonably sure. As soon as one of your dependencies gets a major version bump with incompatible API, the clock starts ticking.

[nequo]

I have no experience with refactoring a Python project. Wouldn’t type hints make it only somewhat more painful than refactoring Rust?

[lostmsu]

Only if they are consistently applied.