Comment by jatone | Hacker News Reader

Comment by jatone | Hacker News Reader

Parent Full thread

this is entirely BS. if by complex you mean overly abstracted and useless boilerplate then yes. java is larger and more complex.

and your assertion about the runtime only being able to do so much is just wrong here. golang will slow down your application in order to meet GC deadlines.

however its incredibly rare to see GC STW pauses for longer than 10s of ms. not even sure its possible given how the GC is written. this is true for heaps in the 100s of GBs.

this is why you don't hear about issues with golangs GC since like ~1.7. it just doesn't show up in 99% of use cases.

your basic assertion that java's GC is more advanced and therefor better is completely without merit. GC doesn't operate in isolation. java has more complicated GC systems because the language mandates them. golang entirely sidesteps the issues java has requiring said systems with better memory layouts and utilizing the stack.

its incredibly rare to hear stories about golangs GC because its simply not a problem.

java still has a bunch of issues and requires different GC tradeoffs as a result. meaning java will likely be in a constant state of 'which GC model do I use'

Have you followed this very thread?

> golang will slow down your application in order to meet GC deadlines

Hardly a good thing for throughput-oriented applications. Java let’s you tune this (the default G1 collector has a target pause time parameter, and then there is also the two new low-latency GC, Shenandoah and ZGC which has <1ms maximum pause time.)

> golang entirely sidesteps the issues java has requiring said systems with better memory layouts and utilizing the stack.

As mentioned many times, having value types greatly decreases the amount of created garbage, thus a less-modern GC can be enough for most Go applications. But there absolutely are use-cases where new object creation is unavoidable and java will beat Go by a huge margin, due to its more advanced GC, see:

https://news.ycombinator.com/item?id=29323468

> Have you followed this very thread?

indeed i am, people seem to having issues dealing with the reality of the two languages. One (golang) the problems you encounter with its GC are easily remedied using memory pools or adding compute. The other? you don't really have a choice without fighting against the language itself. or relying on improvements to the GC itself. which is precisely why java has had to spend so much effort on their GC to reduce latency while golang has been able to achieve extremely similar results with a fairly straight forward concurrent mark and sweep.

> Hardly a good thing for throughput-oriented applications.

add more compute. problem solved. its extremely rare to have situations where you can't add more compute to the problem. that's the point. you can easily solve throughput issues with compute. you can't solve latency issues as easily. if your STW GC pause ends up being 30s+ you're fucked. period.

if you're GC is the source of the problem because of garbage generation, generate less garbage. in go that's generally very easy. in java its very much not.

>beat Go by a huge margin, due to its more advanced GC, see:

you mean the advantage that entirely disappears with a memory pool added in like 4 lines of code? doesn't sound like a huge margin win to me.

I've never once asserted java's GC isn't amazing for the problem its solving. I'm asserting its completely unnecessary in golang because golang allows avoiding the garbage to begin with.

you: 'JAVA GC IS AMAZING COMPARED TO GOLANGS!' me: 'who gives a shit in practice golang memory allocation problems are trivial to resolve'

its the in practice of dealing with reality of the two languages I care about not the self inflicted problems java forces on developers.

Reply on news.ycombinator.com