The advantages of modern syntax design coupled with a fast native compiler would be a potent and exciting mix.
If we're shooting for the stars, though, I'd personally prefer something more ambitious than Go, like GOAL[1].
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.
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.
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:
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?
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.
Also, a good comment by Mike Pall (the LuaJIT implementer): http://www.reddit.com/r/programming/comments/badl2/luajit_2_...
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)