This is interesting. There haven't been many instances yet where Go's memory/GC performance is compared directly and favorably to Java's performance.
Found some interesting discussion here about this: https://news.ycombinator.com/item?id=10149961
We really are looking for raw performance, but not at any cost. I spent a bunch of time, and continue to do so, to eliminate extra work, indirection, and garbage.
Efficiency of runtime and development is a careful balance that Go fits well. Rust is immature. C is difficult for people who haven't been writing it professionally. Java (less Zing or other special cases) is too latent, even if it's very fast when it's running because of HotSpot optimizations. The list goes on, but I didn't see a reason to choose the others over Go, nor have I found something yet that beats it for our use case.
Really, Java just wasn't the language for the job. Go has a lower level and simpler interface, simpler runtime (with less indirection), and better model for concurrency. Yes, it's a new language for us, but it was the right tool for the job. Our garbage collection pauses are mostly under a millisecond, so they aren't really an issue.
Zing never really was on my radar. Looking at it now I shudder to think of the licensing costs, especially since we run tens of thousands of cache instances. We already pay enough just to run these servers. It's also a new Java runtime which very few people know about, and probably nobody at Netflix has used. I would have had to learn it all independently and continue to be on my own from then on. The Go slack team and community in general are very helpful and supportive, and I would speculate that the same level of support isn't available for Zing without paying.
Azul Zing is extremely expensive for commodity hardware; that's a massive price-tag for just the lower latency constraint. Their pricing model is a much better fit for vertically-scaled services, though they even argue that it can lead to reduced costs on horizontally scaled services, presumably on the assumption that you can use fewer hardware instances at peak to handle latency guarantees:
> With Zing, Azul has created the most scalable Java Virtual Machine (JVM) for enterprise workloads and made it available on cost-efficient commodity hardware. With Zing, enterprises can now dramatically simplify Java deployments by using fewer instances while achieving greater response time consistency under load and dramatically lowering operating costs.
- https://www.azul.com/products/zing/zinqfaq/#importance-produ...
Somehow, I don't see a cache solution working well with this pricing model. The underlying operations are presumably simple enough you can get the performance you want with thin, simple software deployed on many commodity machines.
But that's is just my outside looking in take on it.
Java uses about 2-10 times more memory most of time compare to Go. So I'd think Java's GC has to be at least 10 times better/sophisticated than Go's. Though I doubt if it is really 10 times better.
Edit: blogger doesn't do SSL on custom domains. Sorry =/
Screenshot:
http://storage8.static.itmages.com/i/16/0525/h_1464199626_32...
That said, I'm not being redirected and I don't know why gp is.
The https is broken on that site.
