The good news is that computers seem to be fast enough to allow game developers to work in less than speed-optimal languages, so long as they are willing to accept some stylization. Consider Minecraft, easily the hottest indie title in years, and it's written in straight-up Java. (As far as pure numerical computation is concerned, Java is actually a pretty good match for C++ these days, but 3d graphics remain a fairly serious bottleneck.)
If we're shooting for the stars, though, I'd personally prefer something more ambitious than Go, like GOAL[1].
Game developers don't only use it for speed. Mainly for portability. With c/c++ they can make (portions of their) code run on xbox/ps3/nintendo wii/ds/iphone/whatever.
Syntax doesn't really matter in terms of performance - what matters is compiler optimizations. Theoretically someone, if they had a mind, could optimize a Python compiler to run just as fast as C (or at least as fast as a non-statically typed language can run).
With that in mind, perhaps some sort of modification to the JVM (or a competing VM that isn't controlled by Oracle) that provides an aggressively raw metal code would be an ideal future - the advantages of whatever language you want to use + speed and portability would be awesome.
LuaJIT (http://luajit.org/) performs quite well. While I can't say it'd be impossible, optimizing Python similarly would be much harder - Lua's tiny implementation and tendency to do everything in terms of a small and orthogonal group of concepts means it has far less that needs to be optimized. Python is pretty hairy in comparison.
Lua seems to have a similar advantage over Javascript, as well. LuaJIT beats Javascript V8 by a wide margin (http://shootout.alioth.debian.org/u64/benchmark.php?test=all...). It's not like Javascript implementers lack resources, either. LuaJIT is the work of one person.
> Syntax doesn't really matter in terms of performance - what matters is compiler optimizations.
Yes and no. Slight semantic differences can close off optimizations. There was a great discussion on LtU that pulled in a lot of JIT developers. Mike Pall (LuaJIT) tossed out some optimizations the Tracemonkey developers could exploit, but Brendan Eich pointed out that js can't use them:
Huh, cool - I never really looked into what goes into doing compiler optimizations.
What sort of gains would we be looking at with syntactic language differences taken into account?
For instance, suppose I wrote some program in C, compiled, and ran it with the latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down to bare bytecode with a comparably optimized compiler - no interpreter or JIT happenings - would there be a large number of optimizations that just couldn't happen for one language or the other?
You have to think about what invariants the compiler is capable of recognizing in your code, and can prove are valid: "If I guarantee X, it can do optimization Y behind the curtain, but will still run as if things were compiled normally."
For example, if all variables are immutable by default, they can be inlined at point of use, skipping a lookup. Functions whose arguments are all known can potentially be run once at compile time (partial evaluation). Collections can potentially be handled in parallel if each cell's processing is independent. Etc. This sort of thing is why languages with strong invariants (such as Haskell or Erlang) can do really interesting optimizations.
On the other hand, if the language semantics require that everything is polymorphic and has to be looked up at runtime, that adds extra overhead, and it's not always provable what those values will be at compile-time. A JIT-compiler can compile at runtime, when the information is available, but since they're usually not able to pause execution for long, they can't do extensive analysis. JIT compilers can also make optimizations not statically available because they can revert to the non JIT'd code and recompile differently, whereas static compilation is permanent. (Method lookups can also be cached, of course.)
Incidentally, normal Lua (i.e., not LuaJIT)'s compiler doesn't do much analysis - it's tuned for vacuuming up huge dumps of structured data, rather than trying to generate optimal bytecode. Lua usually still runs significantly faster than Python or Javascript, but that has more to do with the the clean language semantics and high-quality implementation.
Well, for one thing, Python guarantees that objects can be dynamically modified (methods can be rebound, new methods can be added, methods can be removed.. same goes for data members. Python can do this because the methods are stored in a dictionary which gets looked up by method name at runtime). This will never be as fast as a static function call in C or even an indirect vtable-based call (indirect pointer access vs hash table lookup).
That is a single reason why Python can never be compiled to run as fast as C. I'm sure there are plenty of other features that help or hinder performance optimisations. Its all about tradeoffs. (Of course, a suficiently advanced language may allow you to choose these tradeoffs at a finer grain than the language level)
Regarding "3d graphics remaining serious bottleneck" :
any serious 3d graphics is done on GPU.
C++ does not have that much advantage over Python or Java, as long as 3d computations are done on GPU
The advantages of modern syntax design coupled with a fast native compiler would be a potent and exciting mix.