| C++ is an old language, and may not be evolved the best way possible, because it set the path, didn't follow a trail opened by another language. The ecosystem's state is different depending on your perspective and what you are trying to achieve with it. While C++ is touted as a general purpose language, it's overkill for most of today's tasks. I use C++ to write high performance and low level code. It's my favorite language to work with, but I'm not using it blindly for everything. As a person who worked with C++ a lot, and still developing something (which I'll eventually open source) for almost a decade, I can say that most of the things you say are not completely correct. > different lang. features implemented, various bugs, quirks, wtfs, various perf. characteristics... You can opt to not use any of the compiler extensions and have a completely portable code. Said code compiles in GCC, LLVM on macOS and possibly in MSVC, and uses CPU at its highest potential (verified on Linux with perf, in turn verified by timing on macOS). Intel's compiler creates fast code for Intel's processors, but it needs intel's patched libraries, etc. It's not worth it most of the time, and GCC already creates pretty fast code. In my discipline compiler cross-compatibility is king. So Intel's is not that important for our case. > Long as hell compilation times. This is fundamental problem yet still that diversity didnt manage to solve it. You can re-compile only the changed parts in any compiler for ages. This shaves a lot of time from compilation and linking times. Again this is neither novel, nor new. > Many package managers The idea of packages born with Java for enterprise software and became ubiquitous after that. Languages have their own package managers to prevent this, but it doesn't always work. Having an "official" package manager doesn't prevent from bringing in a "New and Improved (TM)" package manager to the ecosystem. Also, Rust is a young language. C++ is well, 35 years old? It's inevitable that we have better solutions for the issues we have at hand. > And mediocre lang by modern standards on top of that. Minefield++ would fit it better. It's a language with unfettered low level access. It's a sharp knife (or fighter jet). Learn how to handle it, and it won't bite. It's never guaranteed to be fluffy like Go, Python or memory-safe (to a point) like Rust by adding hard barriers. On the other hand, being semi-conscious about what you're doing prevents 99% of the problems in C++. Said code had memory leak once, during initial development, and fixed on the spot (I test my code with Valgrind), and is memory-sane since that day. That code is not something simple. It's a scientific application which makes your cores and memory controller saturate. It takes every bit of performance offered by your system and converts into science. > Theres still competition between langs Yes, but that's another matter, which is not subject of this discussion. > I also dont fully understand why you treat lang as a standard instead of product. Because a language is a language. Not different from mathematical notation or human language. Compiler is the product, which transpiles that language to another language (incl. machine code) to run on your PC, mouse, microwave or plant based biologic computer. Compiler is the product. Language is just a language. Sets of rules, a standard even (like C++ is an ISO standard). |