4 ms·

I’ve been using Go for 7’ish years across a large codebase, comprising multiple services interacting with millions of people. Every release Go gets better and

I’ve been using Go for 7’ish years across a large codebase, comprising multiple services interacting with millions of people. Every release Go gets better and requires 0 changes to the code. I have never needed to fine-tune the GC. I have never needed to spend a month rewriting my code to work with Go 2.0. I have never been nervous to update to a new Go version. I write the code once, and it runs great in prod for years. I love and value these things. I also suspect that Lichess’s use case would perform extremely well in Go out-of-the-box, since it’s just a web app. I certainly hope the JVM team would like Lichess and other web apps to run well without needing arcane configuration knowledge gathered over years of experience and battle scars in production.

lmm 4y ago
> I’ve been using Go for 7’ish years across a large codebase, comprising multiple services interacting with millions of people. > Every release Go gets better and requires 0 changes to the code. I have never needed to fine-tune the GC. I have never been nervous to update to a new Go version. I've had the same experience with the JVM, over a longer time period. You hear about this because it's exceptional and interesting, not because it's the norm. "Just a web app" is an incredibly reductive take. The same problem exists in the Go runtime (it's fundamental to the problem space), and since they don't let you tune it presumably they either guess or hardcode what the value should be; good luck if they get it wrong. Sure, you probably won't hit it with your code - the overwhelming majority of Java users don't hit this kind of problem with their code either.
- Buttons840 4y ago
  The JVM is a runtime virtual machine. Go produces static binaries (I think?) that run on the CPU, big difference.
  - lmm 4y ago
    Go produces binaries but those include a substantial runtime, with e.g. garbage collection and full reflection.
winrid 4y ago
They're not tuning the GC, really. They're tuning the code cache. That's what the main culprit was. Go doesn't have a JIT. No code cache to configure.

lmm 4y ago

> I’ve been using Go for 7’ish years across a large codebase, comprising multiple services interacting with millions of people. > Every release Go gets better and requires 0 changes to the code. I have never needed to fine-tune the GC. I have never been nervous to update to a new Go version. I've had the same experience with the JVM, over a longer time period. You hear about this because it's exceptional and interesting, not because it's the norm. "Just a web app" is an incredibly reductive take. The same problem exists in the Go runtime (it's fundamental to the problem space), and since they don't let you tune it presumably they either guess or hardcode what the value should be; good luck if they get it wrong. Sure, you probably won't hit it with your code - the overwhelming majority of Java users don't hit this kind of problem with their code either.

Buttons840 4y ago
The JVM is a runtime virtual machine. Go produces static binaries (I think?) that run on the CPU, big difference.
- lmm 4y ago
  Go produces binaries but those include a substantial runtime, with e.g. garbage collection and full reflection.

winrid 4y ago

They're not tuning the GC, really. They're tuning the code cache. That's what the main culprit was. Go doesn't have a JIT. No code cache to configure.