I'm not discounting that the GC had an overwhelming amount of work to do. My comment wasn't intended to convey that the go gc is somehow more efficient, but ra

I'm not discounting that the GC had an overwhelming amount of work to do. My comment wasn't intended to convey that the go gc is somehow more efficient, but rather that I'm thankful for the tradeoffs they've made prioritizing latency and responsiveness, and minimizing the STW phase. I can see how I didn't give enough context for it to be interpreted correctly. It's been my experience that with larger STW pauses, you wind up with other effects -- to the outside observer it's impossible to tell if the service is even available or not. You could argue that if you're thrashing memory that hard, no, it's not available. In general though, it makes for higher variance in latency distributions. > Writing databases is hard. And actually the various JVM's GCs are top knotch and have had hundreds of thousands of engineering hours put into perfecting them for various workloads. no doubt on both accounts. again, thankful for the design tradeoffs. > Still, these days I'm glad not to be near it and I work in Rust or C++. For anything that really needs to be very consistent, or have full control execution, I don't blame you. Cassandra is a prime example of what happens when you don't have that full control.