|
|
|
|
|
by bbatha
1909 days ago
|
|
Go has only concurrency of the features you talk about but is often competitive with Java in benchmarks. In my experience I’ll take administration of go processes any day of the week over Java — I’ve lost count of the number of hours lost to debugging gc stalls, runaway heaps and other garbage collector related issues never once had those problems in go. Go even reverted a generational collector because it had no performance benefits since most generational objects would be stack allocated anyway — Julia’s JIT and way more advanced llvm backend should do even better than go in keeping objects stack local and inline. |
|
So I'm not saying you must prefer Java to Go (even though GC tuning is a thing of the past as of JDK 15 or 16), or that Go's performance isn't adequate for many reasonable workloads, only that 1. a flatter object landscape might still not match Java's memory management performance without sophisticated GCs, and 2. I wouldn't extrapolate from Go to Julia, as they are languages targeting very different workloads. E.g. Julia might well prefer higher throughput over lower latency, and Go's GC's throughput is not great.