To me, as a C++ programmer, none of this really matters. I'm working on a very compute-intensive program with a lot of modules, used in professional settings. I

To me, as a C++ programmer, none of this really matters. I'm working on a very compute-intensive program with a lot of modules, used in professional settings. It has to go fast. If using C++ means we can go faster than someone using whatever else, at the expense of needing five times the people and six times the development effort, we'll pick C++. We're interested in the maximum performance achievable with the language, not the average use-case. Someone would ask "why not assembly/plain C/Fortran/etc.". The answer is that C++ gives you a lot of good ways to structure your code semantically, while still letting you produce tight machine code. That's the real kicker here - I need to reason about my program as an engineering construct running on real hardware, not as an expression of Computer Science algorithms. In a nutshell, for a new programming language to be a viable way to build our core product, it has to 1. Go Fast and let us Go Faster Than Everyone Else, preferably letting me write platform-specific assembly when I need to 2. Interoperate with C++ I've seen a few recent languages attempt to cover 1., e.g. Go, Rust, Julia, for some use cases. However, I have never seen a language attempt to tackle 2. Not even for the case when you have vanilla classes with virtual functions and a few sane templates.