You're comparing Sun's Java 7, a mature mainstream, enterprisey language which has probably the compiler, virtual machine and GC most advanced in all of Computer Science's history, with a niche language that some Googlers hacked together. It would be too naive to expect Go to perform better than Java 7. However...
Notice that Go, compiled with the Plan 9 compilers, performs as well as Java in 7 of 11 tests and uses as much as 1/15 of its memory. All in all, not that bad.
Your also comparing a native compiled language with an interpreted language (albeit with a very good JIT compiler). At some point of maturity, I would expect the native language to edge out Java, and when you look at the benchmarks that is generally what you see.
Except for Haskell, OCaml, Pascal and SBCL Lisp. Java is faster than all of those (on the shootout micro benchmarks), and I'd say all of them are quite mature.
From what I can tell, on the Language Shootout, only C, C++ and Fortran beat Java.
N.B. I think I only looked at benchmarks for x64 quad core.
True that it's slower, but the 'one core x86'-based benchmark comparison is the one it does worst in. And I doubt a one core x86 is hardly typical of what Go code will be running on.
Overall Go loses here aswell, but it does much better than in the comparison you linked, and like others have mentioned Go is still very young compared to Java.
Also, glancing at the tests where Go does really bad against Java they seem to be tests which rely much on runtime functionality, and the Java runtime/VM has had a very long time (+10 years?) in which to improve to it's current state.
Some might consider looking at more than just the time dimension though... Much more memory and more verbose code. I find that this adds up in real systems as there is less to tune for optimal performance and less code to audit.
Do most people using Go in production use the Plan9-derived Go compilers or GCC? Are there any realistic programs where the Plan9-derived compilers generate better code?
I dare say that the Plan9-derived compilers are used predominantly on all platforms they support.
As for code performance, GccGo atleast seems to have the upper hand in code which doesn't rely much on the runtime functionality, but not by very much on the (admittedly few) tests I've done compared to the Go 1.1 6g compiler.
That said, AFAIK GccGo doesn't yet have the improvements made to the Go runtime in 1.1, so chances are it will beat the Go 1.1 6g compiler even in runtime reliant code once those improvements make it into GccGo.
Even so, the official 'plan9-derived' compilers have been improving greatly during their relatively short existance, and as they are the main target of optimizations/improvement aswell as being 'Go specific' they will likely end up generating faster code for Go in all scenarios.
I see GccGo mainly as a solution for platforms to which Go hasn't yet been ported (or perhaps never will), and I think it will remain as such. The main focus, and practically all the end usage will be on that of the official compiler suite.
It will be interesting to see how much more performance they can squeeze out of Go compiler optimization, GccGo has proven that there is more to be had.
I would also like to see profile guided optimization on the Go compilers, I've had cpu intensive code where GCC has given me 10%-20% better performance on PGO builds (this was not Go code, I don't know if GccGo supports PGO?).
Many of the optimizations in gccgo are going to be hard to port to a compiler that doesn't use SSA form. Go has a very reasonable reason to not use an SSA-based IR--compiler performance--but I think it'll be hard to perform the same kinds of optimizations without regressing compile time performance. (If they can do it, though, my hat is off to them!)
Everyone I know uses gc. The only reason why I once considered using gccgo was because gc isn't available on Solaris. Changed jobs in the end, though, so don't have to use Solaris anymore.
Definitely looking forward to the final article in the series!