Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage.
Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasonable, because C++ isn’t safe enough for most needs. Second, we invest a lot of energy into making C++ safer, with better tools, safer libraries, changes to compilers, static analysis, run-time instrumentation, etc. It won’t close the gap—C++ is still unsafe and will be for the foreseeable future—but it will make a big difference to the people who, for whatever reasons, still use C++ despite its safety problems.
The C++ FAQ has a better picture here:
https://isocpp.org/wiki/faq/big-picture
> In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.
There are a lot of good reasons to use C++. C++ is also unsafe. Both are true.
We don’t need to write long apologia explaining why C++ is actually safe, and you shouldn’t be looking at legacy code, or you need to hire better programmers, or you’re using the wrong tools or wrong practices or something like that. Ultimately, those arguments don’t withstand scrutiny.
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."
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.
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.
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.
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.
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.
and a core part of getting this right is the maturity of other features, like generics/templates, duck typing instead of or in addition to inheritance, portable and well defined data memory layout, ease of reuse of existing mature C++ libraries (think numerical Fortran). I consider a language defined module system, straightforward parsing and higher level concurrency (like channels) almost icing on the cake...
nobody is served with a forced rush from one idiosyncratic complexity to another.
and imnsho the core issue with C++ is _not_ "safety" but complexity, of the language as such. it's just way to easy to write leaky or out of bounds writing code, in C and still in C++.
and in that vein I really love carbon and Herb Sutter's Work and get me right, also rust and even good old Ada got a lot right.
but please, can we discuss the better, next gen systems language as if it were not religions? but technology choices with ups and downs?
The first step to solving a problem is accepting reality. Cpp has been foundational, like C, to our computing world. If the rich legacy of libraries that underpin our "better" language choices is offensive to us, or if we really believe we are powerless to improve the situation around the most popular programming language(s) then we're not being realistic.
This is a huge debate of national importance and it'll shape programming language design for decades, it's important to get this right, and that will take more than just once choice and more than one approach to get right.