| > 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. |