Hacker News Reader

> Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster.

Real world programs disagree. And for any large program, the JVM is a superior optimizer than golang's compiler.

> As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those.

I heavily disagree. I deployed services both in golang and Java/JVM languages, and simplicity of the language or runtime has nothing to do with the JVM having superior observability and monitoring.

> you don't need something heavy like JFR

I wonder why my employer is spending millions of dollars on dev salaries to build something not even remotely comparable to the JFR for their golang programs then.

Secondly, the JFR is extremely light weight, and gives you < 1% overhead at runtime. Show me another ecosystem that gives you this out of the box.

> Same story with the GC Java offers, too much choice, too much burden on the programmer.

It doesn't really. The newer GCs have very few knobs to turn. Compare to when you hit GC issues in golang, the solution is to rewrite code in nonidiomatic ways as we saw with Discord. The first approach is superior.

I urge you to look into Javas new ZGC. It's a massive achievement, having only <1ms pauses even on TB sized heaps. Go:s GC can't hold a candle to it in terms of low consistent latency.

> As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those.

Sure, Java has much more need of dev tooling than Go. But the available dev tooling on Java being enough better than the Go tooling to make the language + tooling have a better DX can still (if that is one's experience) be a valid advantage, for anyone not working in an artificially constrained environment where they are forced to code with Notepad and no tooling.