sgmansfield
Tracking the Stars
GopherCon Talk: Creating a Custom Serialization Format
Responding to everyday bigotry
Nanolog: Super Fast Logging for Go
For your second question: I don't believe there is a way to use a separate assembler.
A Foray into Go Assembly Programming
1. You use less bandwidth in/out of the box. This matters in AWS because your bandwidth is (relatively) limited.
2. Your CPU usage to (de)compress is distributed over a larger fleet. The clients spend the CPU time, not the cache servers.
Goroutree: A tree-based set made of coordinating goroutines
Go proposal: clarify how proposals are evaluated
List of TCP and UDP Port Numbers
Also I'd like to know what you would consider an appropriate amount of assembly code.
Iris framework author exposed for license violations
Managing Syscall Overhead with crypto/rand
For example, what happens when I specify a range of 0..100 for a 32 bit int? what if the value is too big for the range? APIs around small operations like this introduce ambiguity that wasn't present before.
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.
edit: No SSL on blogger custom domains. Sorry =/
Edit: blogger doesn't do SSL on custom domains. Sorry =/