Hacker News Reader

Comment by mosdl | Hacker News Reader

We (a team that has extensively used JVM before) went with Go primarily for the GC characteristics and WASM support. GraalVM was promising but seemed like it had a way to go when we prototyped on it.

I do miss the nice IntellIJ java features.

View on HN

The GCs on the JVM are superior to what golang offers. You have several to choose from based on the use case you have (batch processing, web backend, latency sensitive ,etc.).

With a small team, the idea of having different jvm settings per service was daunting as we so far have found Go to work well for all use cases.

We also needed fast start times and hopefully graal continues to mature. We also worried about graal costs given oracles history.

In my experience, you only need to start looking at GC parameters once you hit a certain scale. For the majority of services you'll be writing, especially in a small team, you don't have to worry about them. G1GC is really good, and if you need low latency, you have ZGC and Shenandoah.

We've seen the hoops that people had to jump through to get golang GC to work properly once they hit a certain scale.

The main reason we chose Go was compilation speed since our product would need to quickly compile and generate something that is fast to startup, and Graal was just too slow when we prototyped things.

The GC benchmarks we did showed that Go would work as well, so we begrudgingly moved to it.

The community edition is free and has a GNU license.

Your team required a worse GC?

really ? even with ZGC ?

Reply on news.ycombinator.com