All the complaints I’ve mentioned—from awkward names and slow containers to the static zoo and invisible copies—ultimately lead to the same conclusion. People think C++ puts performance above everything else, but in reality, its highest priority is backward compatibility. Performance comes second; developer ergonomics come second; the overall programming experience comes second. Everything comes second.
That commitment to compatibility is exactly what turned the language into the abomination it is today. You can’t rename vector because it would break billions of code lines. You can’t make unordered_map significantly faster because it would change the ABI. And you certainly can’t introduce destructive move semantics—the opportunity passed more than a decade ago, and breaking existing code is simply off the table. Every wart in the language is a fossilized consequence of some long-forgotten design decision. You can’t remove it because something already depends on it: someone’s library, game engine, application, or entire build pipeline.
Ironically, the very thing people criticize C++ for is also the reason it powers such a large part of software over the world. Backward compatibility is both the language’s greatest flaw and the key to its survival. Code you wrote twenty years ago will often still compile today—with a bit of tweaking and the occasional ritual sacrifice. Even an abandoned library from 2008 can link to a modern application.
I only partly agree. I think that backward compaltibility and ugliness and complexity are not necessarily connected. Take Common Lisp, which is one year older than C++. Common Lisp has better backward compatibility than C++, a large, completely standardized Library, quite performant implementations some which generate native code, and, while it is certainly a large language, it it still is much simpler and the had very little changes, so that 35 year old programs will work without problems.
And the successors, which are the Schemes, also have good implementations - for example Guile - , and when using an implementation that can link with the C ABI (like Guile), is a really nice complement to Rust. In fact, just as Python and C, they can make a nice (and much more modern) combo for rapid prototyping and performance-oriented compiled language.
I only partly agree. I think that backward compaltibility and ugliness and complexity are not necessarily connected. Take Common Lisp, which is one year older than C++. Common Lisp has better backward compatibility than C++, a large, completely standardized Library, quite performant implementations some which generate native code, and, while it is certainly a large language, it it still is much simpler and the had very little changes, so that 35 year old programs will work without problems.
And the successors, which are the Schemes, also have good implementations - for example Guile - , and when using an implementation that can link with the C ABI (like Guile), is a really nice complement to Rust. In fact, just as Python and C, they can make a nice (and much more modern) combo for rapid prototyping and performance-oriented compiled language.