[jeremiep]

There's a world of difference between a web server handling each requests within ~1-30 ms and a game simulating the entire world made from thousands of entities under ~16ms.

It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so. Note that unless you're writing a Gears of Wars, you don't really need such performance and productivity wins once again.

[Guthur]

"It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so."

Sounds definitive, interesting considering that in some cases languages like OCaml outperform C++.

C++ does not mystically provide good performance. Knowledge of algorithms and appropriate data structures are far more beneficial.

Does the coder know how to come up with something like http://en.wikipedia.org/wiki/Fast_inverse_square_root or the cost of a hash map verses indexed array lookup. These will win you far more than any language choice.

[jeremiep]

I completely agree about knowledge of algorithms and data structures being far more important to programming than the choice of language.

Many languages can outperform C++ in some cases and this language it would not be my choice for a next-gen game engine either (D would be).

The thing about going native, however, is that you also control the memory layout of these data structures easily to lower cache miss rates. You can write highly performant code in all the cases where its needed. For a game engine that's very likely to be most of the sub-systems updating the game objects and interfacing with the hardware. Writing native code makes it pretty straightforward once you learn to structure your data for cache locality and prefetch the memory when you know its going to be needed. Video game engines are chock-full of use-cases for this.

I'm mostly a functional programmer now and I do love referential transparency. It's perfect to reason about the logic of our programs and has completely changed how I view software now. But the tradeoff for this is that we lose the ability to easily reason about the execution speed of our programs without deep knowledge on how it gets compiled, and is usually dependent on the compiler vendor.

For real-time applications crunching tens of thousands of objects 60 times a second running sometimes on sub-par hardware written by armies of programmers straight out of Java-School, this makes C++ a no-brainer.