[kaba0]

Low memory consumption also has a price in this case. On a 1 TB server machine guess which platform will have better throughput by far? Go’s GC will die under that load.

Writing a “hello world”-scoped microservice is a tiny niche.

[Thaxll]

Microservices are 100x more popular than app than need 1TB of memory.

Also have you proof that Go will die under large memory usage? It's FUD.

[vips7L]

> Also have you proof that Go will die under large memory usage?

The Debian binary-tree test is designed to create a ton of allocations and stress the GC. Go comes in at 12.23 seconds with Java at 2.65 [0]

Discords famous article about moving a service off Go because of GC issues [1]

I think there is definitely enough evidence to suggest that Go’s GC does have performance issues and doesn’t give you the knobs to tune it.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[1] https://discord.com/blog/why-discord-is-switching-from-go-to...

[Thaxll]

One benchmark where Go is slower than Java, what about the others where Go is faster or as fast but use between 2 and 20x less memory, looks like the GC is not that bad after all.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

As for Discord it was a specific use case, it does not means Go has specific GC issues overall. How Java would have compared against Rust? 100% sure it would have performed worse, but you can't say for sure that Java would have performed better, especially after a re-write, rewriting the Go Discord Go in Go could have fixed the issue, no one knows.

[vips7L]

The others don't matter as we're talking about GC performance under load. Moving the goal post to benchmarks that don't involve putting the GC under load aren't relevant to the conversation.

[Thaxll]

So all memory in Go is managed by the GC but somehow other benchmarks don't matter, right ...

The JVM is probably heavily optimized for what a binary tree is doing, does not mean the JVM overall is better for all use cases.

[kaba0]

The stack is not managed by the GC in the ordinary meaning so.. benchmarks that only allocate on the stack literally doesn’t matter.

And by “what a binary tree is doing” you mean like.. garbage collecting no longer used objects? Like, why is it hard to believe that the runtime on which perhaps the majority of serious, huge web services run (twitter, apple’s web services, but google as well are huge java shops), the likes of which handle 325,000 transactions per second (Alibaba) underwent a tremendous amount of engineering and in the GC category is definitely the queen?

[kaba0]

Go has an advantage in the niche cases where you can get away with value types. But that is a very rare use case, reminiscent of embedded programs. You almost always need heap allocations, especially for long running, large apps — and Java has the state of the art GC implementation on both throughput and low-latency front.

[Thaxll]

Well your "niche" use case is one of the reason why Go uses less memory than Java most of the time.

[super_flanker]

Other benchmarks don't stress the GC enough, only the binary-tree one does.

[kaba0]

Sure. What about apps that need 300MB. Or a few GBs?

Where you can get away with barely any allocations is a much smaller niche even for microservices. And Java’s GC is in an entirely other generation of GCs compared to Go’s.