You're right with your first point, but wrong with the second: a lot of new projects are still written in c++. Pretty much every non-indie video game, for example.
So code that relies on a lot of existing software then (ie the game engine and other in-house libraries that any company would have). You have proved his point instead of countering it.
I don't know if the JVM is better or worse for this than some other runtime like Go's or the CLR or whatever, I just wrote about the JVM because it is the one that I have used in this context.
1. There is a lot of expert tuning to get that sort of performance with respect to latency. That tuning would need to be reproduced for every target system.
2. Those trading systems can have ridiculous amounts of RAM to give the JVM GC lots of room to work with.
3. Reading packets from a wire and writing other packets to a wire is a different problem than reading controller inputs and modelling complex 3D worlds.
...that's not to say you can't have AAA Java games. To some degree that already happens with Android games, at least if you're willing to stretch the definition of AAA. (If you define AAA as "uses C++", the nomenclature becomes fairly moot).
My response is that we use C++ for the language itself, existing engine or not. :)
There are toolchain requirements that push in this direction, but honestly I doubt they make any significant difference in the matter.
Not even fully on C++11 yet!
Vil: How's it going?
We'll hopefully be moving to compilers capable of supporting c++11 at work soon - maybe even in 2016 if we're lucky - but it'll probably be an even longer wait before we can start using c++11 features in our code. Still, a guy can dream...
Yeah, there's a bit of c++11 going on here - but until all the DCC apps move next year, as you say, it's going to be a while.