Every thing depends on the use case, and one case always find special case as counter example and most engineering solution/choices.
Generalization are still useful and sometime "true". C++ (and native languages) are faster than java simply because it was designed this way. C++ chose speed at the price of complexity, safety and build time. Java on the other hand focused on simplicity and safety.
I understand the idea of wanted to bring nuance, but the"it depends" can also become an excuse for bad tech choices.
> There are plenty of cases where Java will be faster than c++ purely due to the available libraries.
Hard to believe, but in that case i would say that you are comparing libraries, not the languages.
If that were true, C and Rust (which are typically faster) would be just as complex as C++ (but no language is).
It chose to jump into the OOP fad while staying low level ("what if we had C with classes?"). That's the cause of most of the complexity. The rest is age, backwards compatibility handcuffs, and kitchen sink stuff from other languages like move semantics and functional stuff.
> Java on the other hand focused on simplicity and safety.
Java chose to jump into the OOP fad while being high level. Ruby and Python did the same thing, and they're also simple as a result. That or low level and not OOP are the correct combos if you don't want to wind up with something as byzantine as C++.
> If that were true, C and Rust (which are typically faster) would be just as complex as C++ (but no language is).
I don't think that this assertion follows from my statement.
It's totally possible that there exist simpler languages which give exactly the same level of performance and expressiveness as C++ while being simpler. Nobody said that the C++ design was optimal with regard to the complexity/zero cost abstraction ratio. Bjarne him self think so (https://www.stroustrup.com/quotes.html), and both carbon and cppfront are effort in that direction.
The point was that when comparing (as of today) java vs C++ we shouldn't be surprised that a language which has "zero cost abstraction" as a core principle, and which is willing to be arbitrary complex ended up being faster.
With regard to the language you mentioned, C is simpler because it does less... And rust is much more recent and completely rethinks the native language landscape. I am not sure that we had the understanding (or even the tech) necessary to create rust 20 years ago.
But more importantly, i don't really buy the premise, of "are typically faster". Some concrete example would be nice, otherwise from experience this statement is wildly incorrect.
> It chose to jump into the OOP fad while staying low level ("what if we had C with classes?"). That's the cause of most of the complexity
Disagree.
> The rest is age, backwards compatibility handcuffs
Very true, if we remove backwards compact. C++ would be simpler.
> like move semantics and functional
Adding features paradoxically can simplify a language by providing a coherent/unified version of previously distinct usage pattern. uniform initialization is the canonical example.
I would say that move semantics also simplify the language by folding resources reuses patterns inside RAII.
Same for C++ lamda, just simpler syntax ...
So you seems to say that we can choosing to forgo low-level control (ruby,java,python) or general abstraction structure(which is what OOP is really) to would produce a simpler language.
But C++ is exploring a different design question, trying to have in the same language low-level control, and abstraction that are general enough to expression complex design, and which can be efficiently deconstructed as to not impact performance. And the C++ community seems to be willing to pay some level of complexity for that.
I do not doubt that there are domain where the best libraries are in a particular language, and this language might not be C++.
I am just not convince that java is better than C++ with this regard. (as they are more domain where the best C++ is faster than best java one).
But i think that's beside the point, we are comparing language here, so the existing/quality of characteristics of libraries shouldn't be the main focus (beside the stdlib of course).
Now there is more to choosing a tech. stack than just the programming language, and that include the libraries, current knowledge of the team etc. And i would even venture to say that those might be more important than the programming language per say. But i do believe we can still factor those concern out and compare programming languages, keeping in mind it's only part of the story.
What value is there in that exercise? We never use a given programming language outside of a given task/context. Comparing them absent that is navel gazing.
