[chrisdinn]

Teasing this apart I see a few things: a) logging, b) modules rollout and c) missing frameworks.

I’ve never had a logging issue in large systems. Explicit error return (as you know, on every function) allows you to log in your code, not lean on only libraries that support your interface.

Modules rollout was part of growing up. But, you won’t get Go 1->2 upgrade issues as we have 100% backward compatibility on version upgrades. Moving to the latest version of Go is trivial and simply unlocks new features.

Too many allocations for Go is going to be too many allocations for JVM too. This seems like an problem isolated to that team.

I’ve done Go at both a three engineer startup and at Google and I can’t help but notice none of these are really the type of problem that crop up later.

[jpgvm]

Good to hear logging has gotten better.

Though I still don't see a standard web stack. "stdlib is enough" is only true for people that don't need their hand held and/or can organise good standards across teams.

If it was just me or people I know are good writing the software that works. At Google it probably works because of aforementioned hiring bar. At the average large-ish company? Not something I like leaving to chance because I have usually ended up disappointed.

[kaba0]

> Too many allocations for Go is going to be too many allocations for JVM too

No, Go’s GC is a toy compared to the JVM’s. It is lowerish in latency by actually stopping the application threads when under high contention.

Java doesn’t slow down the allocation rate, it tries to keep up with the churn.

[jpgvm]

Even it's latency is outclassed by ZGC and Shanandoah.

The GC monoculture is great from a simplicity and out of the box experience but there is a very good reason to a) want multiple different GCs tuned for different workload types and b) have competition so that the best designs can be found rather than having to fight to be the only implementation.

[geodel]

Huh, Go also does not allocate ten times more more memory like Java. So even if Go's GC is 1/10th performant as Java (and it isn't) it will be equally better Go applications.

Java's GC improvement is relentless because Java's applications are relentless in memory allocation.

Being on endless Java memory/perf issue prod calls I can say Java GC improvement, performance tuning is cottage industry in itself. Meanwhile end users keep suffering but at least Java devs get to tune GC to their heart's content.

[chrisdinn]

I’d love to see you elaborate on this. Anecdotally, my experience was the exact opposite. Is there some documentation making this point?

In the course of optimizing I came to know the various JVM GC algos (concurrent mark/sweep, parallel old, etc) by the corresponding memory graph alone. I never, ever had to debug similar latency in the Go stack.

[the-smug-one]

>> (concurrent mark/sweep, parallel old, etc)

Both of those are only picked for low sized heaps with few cores, probably within a container. Were these micro services?

G1 is the default for larger heaps and multiple cores, and ZGC and Shenandoah (low latency GCs) have to be manually turned on AFAIK.

OP said:

>Java doesn’t slow down the allocation rate, it tries to keep up with the churn.

This is incorrect. ZGC will block a thread when it cannot give a thread any memory, because it can't collect and free memory at the pace needed. Google "allocation stall" for this. ZGC can achieve very low latencies akin to Go's GC, I don't know if the throughput is higher or not. Multiple cores and some GiB of heap space is when ZGC will shine.