I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.

... Says the absolute dearth of Java / OpenGL games besides that, I have to question the sanity of anyone who believes that Java or OpenGL is more compatible or readable than alternatives in practical terms, despite promises of the contrary. The readability of both is perhaps a matter of taste, though.

For the kinds of things that C++ is really good at there really is no viable replacement--maybe D someday, or Rust, but certainly not any kind of Java or C#-like productivity language. The trouble with C++, really, even moreso than C, are the number of potholes you'll encounter on a daily basis. I think this stems mostly from the fact that so many subtleties are afoot that almost no piece of code does precisely what it appears to do, and any piece of code that does perform its purported function precisely probably bears only a passing resemblance--at least, with the way most people write C++. For example, probably any 10-20 line function of C++ that does anything at all non-trivial and which compiles with exceptions enabled probably has 20 or more ways of exiting, often not safely when an exception is thrown.

More idiomatic, best-practices C++ code which relies on proven patterns and facilities like smart pointers, standard containers and standard algorithms is both safer and more productive, but for some reason -- sometimes technical reasons, other times cultural ones -- C++ users are in practice somewhat resistant it seems. Its an additional learning curve that many people percieve as being "outside" the necessities of the language itself -- perhaps because the learning curve of the lange is itself so large. Languages like C# or Java, I think, will always be ahead on the productivity and safety curve, owing first to a shorter legacy, a smaller and more-homogenous language, and the conveniences and safety buffers that their runtime environments supply -- which is a bit like bowling in the bumper lane.

That's the trouble with analogies -- they can mean exactly the same thing or slightly different things simultaneously to different people with different perspectives. I doubt if my bowling analogy means anything different than your car analogy at any less than a stretch.

The point is that productivity languages, and I'd say Java in particular, subscribes to a particular orthodoxy of software development that's meant to protect the programmer from themselves in many respects. Common examples would include garbage collection, Java-specific examples would include things like the lack of operator overloads. The language designers and run-time implementers have decided in various ways that they know what's best for the sanity and productivity of you and your fellow programmers, and outright prevent or make difficult particular usage that they feel is more harm than good.

That's a perfectly valid design constraint if the ends justify the means -- indeed C# and Java are perfectly productive and safe(r) for the paycheck-programmer who really just wants to make things work and go home at 5pm without a care for memory management, intricate exception-safety guarantees, or being fully ISO-C++ compliant. C and C++ take the stance that the programmer is infalible, and means to do precisely whatever hare-brained thing it is that they insist on doing. C++ never tries to tell you its a bad idea, that your operating system will disallow it, or that your hardware is going to balk, it allows you to cast away even the minimal safety checks it does enforce. The thing is that sometimes you really do want to do those seemingly hare-brained things -- like writing your own memory manager, spitting CPU instructions into a memory buffer and then executing it on-the-fly, or transforming an object from one type to another by overwriting its v-table pointer. C# or Java will never completely replace C++ because they necessarily disallow such deep magic, and why other systems languages like D or Rust at least have the capacity to replace C++ if neither the momentum nor the pedigree.

So whether all of that is more akin to bowling with bumpers or driving automatic is really neither here nor there, and I doubt if anyone would care to make a further argument in support of one or the other