Go Creeping In

I’ve seen the inside of the Google and Amazon tech stacks. There are common threads that run through them and also, I bet, through most BigTechCos. Here and there down the stack is a lot of C++ and vestigial remnants from earlier days, Perl or PHP or whatever. Out in front of humans, of course, JS. But in between, there are oceans and oceans of Java; to a remarkable degree, it runs the Internet. Except for, here and there, you find a small but steadily increasing proportion of Go.

If you want to know what’s going on at Google, go follow Brad Fitzpatrick. If you want to know what’s going on at Amazon, I shouldn’t spill those beans without asking for permission, which I’ve never been good at. But I can write about what I’m hearing and seeing when I look around, both inside here and out there on the Internet.

I don’t know of any co-ordinated campaigns, here or anywhere else, aimed at walking away from Java or encouraging Go (or any other replacement) in a top-down way. I do notice good engineers just going ahead and standing up Go-based microservices.

There are a bunch of reasons for this, and lots of smart people have written wise words on the subject. But here are my perceptions.

Readability · I initially fell in love with Ruby because other people’s code was just easier to read than anything else I’d previously encountered. You needed to learn what how blocks work and what |foo| means, then it all just fell into place. Then when, based on that, you figured out Enumerable, you might have had heart palpitations.

Go takes it a step further. You need to get used to type declarations being backward and how interfaces work. Then when you learn about channels and goroutines, you might experience shortness of breath.

It’s amazing — amazing I say — how little generics are missed. To date, Go remains the small, simple language that fogies like me can remember Java being. I suppose that can’t last, but for now, I can pop open almost any .go file and if I can’t understand it pretty quick, the chances are very high that the problem is in the code not me.

Predictability · The Go runtime is garbage-collected, but the GC design is consciously optimized to be predictable and not induce latency; here’s a nice deep-dive. There’s no free lunch, so that excellent latency probably carries a price in throughput. Which for a whole lot of online services is a good bargain.

Performance isn’t a simple subject. But there’s a perception among insiders that Go’s performance is good enough and its latency is low enough. Furthermore, that you can expect pretty similar numbers for P50 and P99.9 latencies. And a Go program starts up fast, which we in the Serverless tribe really like.

Goroutines · They make it easy and idiomatic to arrange that some parts of your computation be done in parallel with other parts. And unlike other concurrency frameworks I’ve fought with, you can pretty well just fling a (potentially huge) number of tasks at goroutines, and empirically, the runtime does a good job of keeping the cores busy and the work flowing through.

And (assuming a little care with buffer sizes) it’s very unlikely that you’ll get a deadlock or an annoying race-condition bug. I’ve never had one and I’ve seen plenty in certain other languages beginning with “J”.

Executables · The fact that Go generates statically linked binaries warms greybeards’ hearts, but I’ve noticed the young pups seem to like that too. And the first time I realized I could type GOOS=linux go build on my Mac and run the output as a Lambda function I grinned from ear to ear.

Speaking of Lambda, the Go runtime has pleased me every time I’ve tried it. Also I built a custom Lambda runtime in Go and that worked great on almost the first attempt, which impressed the hell out of me.

The future? · Nope, no language is, the future is obviously polyglot. But it’s a tool I’m turning to a whole lot, and I’m not the only one.

---

---

Contributions

---