The argument of HN commenter was: look at those benchmarks, Go is 2x
slower than Java.

It’s a simplistic but unfortunately powerful argument: most people won’t
take the time to look at the code to determine that part of the issue is
that Java implementation is simply better than Go one.

By that simplistic argument I’ve improved speed of Go by 20% by writing
a slightly better implementation of the benchmark.

The story doesn’t end here. The above results were for single core x86
machine. If you look at results for single-core 64-bit
machine,
Go actually wins on this and 2 other benchmarks.

The explanation is simple: 64-bit Go compiler is a little bit smarter
than 32-bit Go compiler.

Is Go really slower than Java?

There is no simplistic answer to this, but there are rules of thumb.

On equivalent programs, Go generates programs similar in speed or
faster. 64-bit version will be slightly better than 32-bit version.

Java garbage collector is much better than Go’s which explains why
allocation-heavy benchmarks (e.g. binary-trees) perform so much better
(there’s almost no computation there, just allocation of a lot of tree
nodes).

Go is already competitive with Java and will only get better. Let’s not
forget that Java had over 20 years of investments in code generation and
garbage collection. Go is only 5 years old. There already were compiler
and garbage collection improvements since the latest released version.

One area where Go wins undeniably is memory usage - the programs use at
least order of magnitude less memory. Java is paying the cost of
sophisticated virtual machine.