Go compiler is by far the weakest among those three. GC pause time is a little lie that leaves the allocation throttling, pause frequency and write barrier cost out of the picture. Go works quite well within its intended happy path but regresses massively under heavier allocation traffic in a way that just doesn’t happen in .NET or OpenJDK GC implementations.
You also have to think about your target audience.
Are you hiring developers that are 100% fully conscious of concurrency and starvation or people that are only concerned with rest and vest and TC?
For either case Go is better.
* For people that are aware of concurrency, they will select Go because they appreciate its out-of-the-box preemptive concurrency model with work stealing.
* For people that are not aware of concurrency, then you should definitely use Go because they are not qualified to safely use anything else.
That’s why I specifically qualified my comment “within the context of a typical crud api server”.
I remember this being true 10 years ago. Java web servers I maintained had a huge problem with tail latency. Maybe if you were working on a 1 qps service it didn’t matter. But for those of us working on high qps systems, this was a huge problem.
But like I said, I know the Java people have put a ton of work in to try to close the gap with Go. So maybe this isn’t true anymore.
You can't compare 10 years ago Java to current Go. 10 years ago was Java 8, we are currently on Java 23. The performance difference is massive between these 2 runtimes especially between the available garbage collectors.
Hazelcast has a good blog [0] on their benchmarks between 8 and some of the more modern runtimes, here is one of their conclusions:
> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pause
Typical CRUD API server is going to do quite a few allocations, maybe use the "default" (underwhelming) gRPC implementation to call third-parties and query a DB (not to mention way worse state of ORMs in Go). It's an old topic.
Go tends to perform better at "leaner" microservices, but if you are judging this only by comparing it to the state of Java many years ago, ignoring numerous alternative stacks, it's going to be a completely unproductive way to look at the situation. Let's not move the goalposts.
