10 ms·
People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people st
by tzone 2mo ago
People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM.
It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all suck in different ways.
- Pooge 2mo agoI'm the biggest fanboy of Go, but since Java 25 the default garbage collector (ZGC) is very similar to Go's.
- hashmash 2mo agoLow pause collectors like ZGC and Shenandoah must be enabled explicitly. G1 is still the default. It should also be noted that the low pause Azul C4 collector was available in 2010, but it was a commercial product.
- Pooge 2mo agoYou're right; apologies! I set the JVM flag quite some time ago, haha.
- age123456gpg 2mo agoVery similar, in the same way non-compacting and non-generational collector is similar to compacting generational :shrug:
- tzone 2mo agoGarbage collector alone can't do what happens in Go language+runtime. Simplest example is that there is no way to allocate fixed arrays with non-pointer structs in Java. That is just not possible in the language. Design of Go allows programmer to rewrite their program to make it as GC efficient as needed. You can even have essentially zero GC overhead and do stuff manually for really high performance needs. And you can also write regular code when GC isn't a big deal. Those options simply don't exist in Java language. Your only bet in Java would be to embed some C code which is a nightmare of its own. There is a reason why almost all backened systems that run on JVM are a huge pain in the ass even at moderate scale. They all end up rewriting parts in other languages and at the end just rewriting the whole thing.
- vips7L 2mo agoThose options will exist soon: https://news.ycombinator.com/item?id=49119063 https://news.ycombinator.com/item?id=49119063
- vips7L 2mo agoPretty outdated take. Java’s GCs are a generation ahead of Go’s.
- bheadmaster 2mo agoYeah, they have to be in order to make up for the braindead decision of making every variable a pointer to heap allocated memory. Go wins not by technical ingenuity, but by simply not making fundamentally bad decisions in the first place.
- vips7L 2mo agoThis will also be an outdated take in a few months. What’s next?
- bheadmaster 2mo agoI assume you're referring to value classes? The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design. Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just provide an opt-in feature with significant restrictions.
- vips7L 2mo agoIt will make criticism outdated with regards to “you can’t do X” when you actually can do X. Your argument still doesn’t refute that that Java’s GC’s are leagues ahead of Go’s. If your argument is that optional syntax is bad, sure, we can do that, but it has nothing to do with GC performance.
- bheadmaster 2mo agoMy criticism was not "you can't do this" - my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible. Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot.
- kamma4434 2mo agoI personally do not care about GC - in the last 15 years it’s been a solved issue. Where imho the JVM rocks, is that you can instrument it in production