[joeblau]

  >  It's often been said that Go solves the problems Google developers have, and
  >  it's 110% true. 

I'm wondering how much of what you're experiencing is "Good Go" vs "Bad Java"? I feel like you can take any project in any language and screw it up pretty badly. I'm an iOS developer and I've seen developers bring questionable practices that aren't consistent with the Objective-C ecosystem in and cause all sorts of confusion. I'm sure there are a few other languages that would give you the same positive experience if you tried them out.

[fixermark]

It's possible that Go hasn't been around long enough for anyone to screw it up badly. But that'd be a strength in the ecosystem of languages.

[iofj]

Many of the comments here evoke that feeling : that Go doesn't have compromises.

History teaches us that this is not in fact the case. Reality is that Go doesn't have too many compromises ... yet. I've run into more than a few already, and the cracks are visible, even if they're not yet too deep or expanding. (e.g. the logging struct, which prevents you from overriding logging destinations or adding logging contexts)

Every language gets a honeymoon phase. Once you program for a decade or so, you'll start remembering those. Java, for instance, had a great, and very long honeymoon phase when the concept of garbage collection and VM based languages was new, at least in mainstream languages. The cracks and compromises are what killed Java, and these days the cracks are regularly in the way, or at least visible.

[qihqi]

Google has to statically link everything to produce a big binary with almost no dependency (besides syscalls), because it cannot promise the environment of the server, as you might get different boxes between deployments. So, it links all the jars and jvm into a huge binary, it's a pain to deal with that because it takes minutes to build and see your change.

And still, Java is almost used for front end only. When memory is not enough, you have to use C++.