There may be historical reasons for this. There may be low hanging fruit for Go. But in the end, all that matters to the consumer of my project is "code go fast?".
"Fair" to companies considering Go right now? Absolutely. If you're deploying a production system, you go to war with the army you have.
A few years back I remember Brian Goetz (I think) wrote in an article that object creation in Sun's JVM was down to like 10 machine instructions (I assume on x86). How much effort will it take to get that down to 9, 8, 7?
On the other hand, choosing a language like Go that (I assume) still has a good deal of room from optimization could over time make applications run faster/better/cheaper without changing a single line of code.
As for the "you go to war with the army you have" idea... that's fine, but by far the biggest performance problems in nearly every application I've seen are the result of programming errors/laziness/deadlines, and there is nothing that any platform can do to optimize away those problems
From my perspective the JVM hasn't seen major performance changes since the early days e.g. Java 4. All of the major improvements have come in the library space e.g. LMAX Disruptor, OpenHFT, Javolution.
They ship new optimisations in more or less every release. I'm not sure what workload you do that you've never seen performance improvements.
For example in Java 9 they're going to ship auto-vectorisation for certain kinds of functional / parallel stream construct.
I am not saying there weren't any benefits from the JVM over the years only that the biggest gains I've experienced have come from new types of libraries.
Fully agree with Java 9 though. It is the first release that I've been really excited about. Project Jigsaw has the potential to fundamentally reimagine the entire platform.
If potential improvement becomes actual improvement, you'll most likely see that result when the measurements shown on this website are updated for that version of Go.
To-date the measurements for Go have been updated 9 times since Go 1.0 (3 years ago) and another 50 times in the 2 years before Go 1.0.
But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game.
I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will. I can't stand benchmarks like this.
Oh yeah, and Java FTW ;)