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

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.

> IDE's

Lack of an IDE is a feature not a bug.

Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have.

> tooling

Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools?

Wrong philosophy in my opinion; I could imagine something better.

Depends the definition of IDE. My IDE is VIM. Why is it an IDE? Because it understand the text I am editing. An editor does not understand it. Anything, that supports programming on the top of an editor an IDE feature in my view. If you definition of IDE is IntelliJ than it is a different problem. I cannot edit Java without it anymore, Java is just too verbose and too many things can go wrong, I need immediate feedback from my IDE to tell me that I am doing it wrong also collapsing too verbose parts is a great thing. I don't use too much of IDE features but anything that I incorporated to my workflow over the years (very little, I keep it simple) is damn useful and I am pretty sure I would be slower without it.

Languages with small clean syntax do not require that much IDE usage, at least this is my experience. I never thought my Erlang workflow could be improved with something like IntelliJ. I guess having a REPL helps a lot.

Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."

Like gosublime?

Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).

Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up.

I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I have better things to do than install editor plugins.

I really don't get the amount of love for gofmt. It's a formatter. wow! amazing! That's never been done before.

Yes, but it had the One True Format, which is the only way it can possibly work. I've used a formatter at other jobs in other languages, and you end up having your formatter fighting with everyone else's, unless they're configured exactly the same, which no one can ever agree on.

It takes me about 5 minutes to setup IntelliJ. And that includes the download.

And I would never want anyone in my team who was doing major refactoring work without an IDE.