On: Ian Lance Taylor's Response to “Go Is Google's Language”

[grumpydba]

Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.

[apta → grumpydba]

Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1].

Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off.

I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics.

Deployment has been solved for a while now with building shadow jars[1].

[1] Not to mention offerings like: https://quarkus.io/

[grumpydba → apta]

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

[apta → grumpydba]

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.

[grumpydba → apta]

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

[apta → grumpydba]

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.

[grumpydba → apta]

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.

[apta → grumpydba]

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.

[grumpydba → apta]

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.