Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).
No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.
I think it's likely that Golang apps won't stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place.
(I'm not saying this is a negative for Java, BTW; making shared memory data structures both fast and idiomatic is really important if you care about performance of parallel code.)
Because "programs don't need more than one type of dictionary, so the language can just hard code one implementation in" is at least a defensible position in a single-threaded setting (although I don't agree with it), but it definitely isn't in a scalable parallel setting.
Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team aren't saddled with years of legacy frameworks which are expected as standard knowledge. The JVM is a great platform, but Java the language and to a greater extent its frameworks are a major liability for the future of the JVM. Go and Java (the language) are both incredibly boring to program in (a good thing in if you have developers of varying skill levels), but they are a safe choice with a low bar for learning. Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.
> Many of the Java monitoring is only critical because of the garbage collection issues with large heaps.
That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application.
And I can only guess that you've yet to encounter Go's even worse GC problems with large heaps.
> Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.
True, but only in legacy codebases. A new Java project is as pristine as a new Go project, and new Java libraries are just as lean (because there's a lot of cross-influence between the two environments).
> A new Java project is as pristine as a new Go project
The problem is that most Java developers have become so familiar with and attached to bloated frameworks that they simply aren't interested in trying any other way. They have a lot of time and effort invested into mastering these frameworks. "Let's use Spring for that", and endless talk of the "persistence layer" for even the most basic apps.
The same developers who would be willing to try Go would also gladly use new Java libraries, and they will be able to preserve much of their hard-earned expertise.
You're implying that the mere switch -- all things being equal -- has an inherent advantage, while I say the opposite: all things being equal, switching languages is always a net loss, other than a possible advantage in recruiting in some regions where HN is popular. Of course, all things are never equal, so there are many other considerations.
