Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.

And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.

Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.

Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap:

    func main() {
        n := 1
        fmt.Println(n)
    }

Object pooling won't help here.

The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.

You can pool n if it's on your hot path, can't you?

Escape analysis was just rewritten, and the objective is to handle this case more gracefully.