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.
