Go does not need 128MB of memory to run hello world in a container.
People don't pick up Go over Java because of goroutines, Java is still and will forever be an "enterprise" language behind many layers of abstractions.
The JVM is a master of gradually closing the gap. Over the last decade:
- Garbage collectors have required far less tuning; with G1, Shenandoah, ZGC it's likely that your application will need little tuning on normal sized heaps.
- modules, jlink etc allow one to build a much smaller Java application by including only those parts of the JVM that one needs.
- Graal native images are real. These boast a far lower startup overhead and much lower steady state memory usage for simpler applications.
Probably my counterexample of choice is this: https://github.com/dainiusjocas/lucene-grep - it uses Lucene, one of the best search libraries (core of Elasticsearch, Solr, most websites), which is notoriously not simple code, to implement grep-like functionality. In simple cases, they demonstrate a 30ms whole process runtime with no more than 32MB of RAM used (which looks suspiciously like a default).
The JVM is fast becoming a bit like Postgres... one of those 'second best at everything' pieces of tech.
FWIW, this criticism no longer applies to people using AOT compilation. From my macOS laptop:
/usr/bin/time -l ./hello-world
Hello World!
0.00 real 0.00 user 0.00 sys
3231744 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
841 page reclaims
1 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
0 signals received
2 voluntary context switches
4 involuntary context switches
22395110 instructions retired
18507246 cycles elapsed
1294336 peak memory footprint
So "peak memory footprint" for hello world is 1.2 MB and it starts instantly.
Now, not everyone can/will use AOT compilation. It's slow to compile and peak performance is lower unless you set up PGO, plus it may need a bit of work in cases where apps assume the ability to do things like generate code on the fly. But Go can't do runtime code generation easily at all, and if you are OK with those constraints, you get C-like results.
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.
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.
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.
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.
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?
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.
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.
People don't pick up Go over Java because of goroutines, Java is still and will forever be an "enterprise" language behind many layers of abstractions.