Is this right? Java really has better latency than Go right now? And with 2 processors, Go's latency is 25ms for 50 concurrent requests. Anybody with better experience care to comment on this?
A little known secret is that most mainstream languages have nice libraries to handle multi-core programming that go beyond basic thread handling, similar to what Go offers.
You just have to know where to look for, plus you don't need to throw away mature languages and tooling.
There's still this lingering belief that Java is slow, maybe related to the terrible start-up times of the JVM. But once it's going, Java is fast - really fast. And since its niche is basically enterprise webapps, a lot of attention has been paid to scalability and concurrency.
1 - There has been a lot of man years put into the JVM (threading and garbage collection), and Java memory model. I'm somewhat surprised by the magnitude of the difference. Java and JVM are very mature technologies.
2 - Go's CPM paradigm is not necessarily more performant than the preemptive threading model of Java, and I don't believe that has ever been claimed for CPM. It is claimed that it is "easier" to write concurrent code using the (CPM/Go) message passing paradigm, but in my experience, you either get concurrency (and can do both variants ok) or you don't, in which case any real world concurrent system will hardly be "easy". That said, for the concurrency novice, Go is far less intimidating experience given the language level support for goroutines (fibers), channels, selectors, etc. (think Java NIO ...)
I have no idea if it is "right" since I'm not going to duplicate this exact benchmark, but it seems likely. Raw performance hasn't been a huge focus for Go, though this has been changing. The tip version produces much faster code than the last official release that seems to have been used here. Also you often get more efficient Go from the gccgo frontend than from the Google compiler since it can take advantage of a lot of front-end-neutral optimizations that gcc already has (though this gap is closing as the Google compiler gets improved). For the runtime, work continues on the goroutine scheduling, gc, etc.
You just have to know where to look for, plus you don't need to throw away mature languages and tooling.