Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones.

Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure.

Anyone who thinks Go is an upgrade to Java is woefully misinformed.

"Let's also not forget that Java is significantly faster"

Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.

As always, it depends on what you're measuring. I find it to be largely a wash

http://benchmarksgame.alioth.debian.org/u64q/go.html

Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.

You say that, but because 1.5 is written in Go, it actually does significantly worse on some benchmarks and actual programs.

See: https://talks.golang.org/2015/state-of-go-may.slide#11

Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.

JVM start-up, JIT, OSR etc take very little time relative to most of the workloads shown on the benchmarks game.

http://benchmarksgame.alioth.debian.org/play.html#java

The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%.

Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that --

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

Keep in mind Go 1.5 has not been released yet :-)

Not the best but the Techempower one is one example:

https://www.techempower.com/benchmarks/#section=data-r9

And arguably more real world than microbenchmarks.

There are cases where the Go compiler generates horrors, and the only workaround is to write your code in asm.

Here's one example:

// imagine a for-loop around this

s := foo[i:i+4]

s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3]

The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks.

I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter.

EDIT: fixed formatting of the example

Some people like things that are minimal and good enough. Also, there is a huge swath of engineers who just really dislike writing Java.

Adrian Cockcroft does and I don't disrespect his opinion even though I'd far rather functional languages won the developer mindshare myself.

We shouldn't be under-selling how light the Go footprint is. In the long run it may be one of the few languages to compete with unikernels.

> In the long run it may be one of the few languages to compete with unikernels.

Can you please clarify what this means? I don't really understand what it would mean for a language to compete with a unikernel.

Most of the benchmarks I have found show go to be faster at cpu things and java to be faster at memory things.

This is no surprise considering that go is a compiled language and the java garbage collector has had decades of very smart people working on it.

   > It's an upgrade in terms of compile times, deployment simplicity, conciseness, 
   > concurrency, etc. Some people care about such things.

I remember the days of going for coffee while the compiler chugged away but I wonder what compiles people do on a regular basis that take such time? I just rebuilt SBCL here on a mid-2012 MBP and it took less than 6 wallclock minutes in the background including download and whatever else I was doing:

   real	 5m12.752s
   user	 4m33.393s
   sys	 0m27.579s

I personally use D when possible, but waiting on compiles is usually secondary to the amount of time I spend thinking or exploring.