Something else about this kind of job cum go: "asynchronous I/O"* is extremely straightforward. Decoupling of the semantic threads ("goroutines") and OS-level threads mean a blocking I/O op only blocks your goroutine, which is cheap. If you are doing heavy I/O, you can still program sequentially. No need to manage I/O event queues, threadpools nor callbacks.

Cherry on top: you never need to worry about blocking libraries, either. Every library automatically fits the model.

It may not have been their consideration, but for anything I/O heavy, this is a godsend.

Sorry for the tangent. This is now biting me on a new project and I feel like I didn't properly appreciate this until I didn't have it anymore..

* from the pov of OS threads

Yes, that's really important for the Git LFS project to us. Of the languages that we're comfortable with, it's the only one that met that requirement.

I feel like there have been a lot of blog posts and HN discussions about the merits and downsides to Go, and I don't really have anything new to add to that.

Speed also. Your hub client is way faster now that you moved from Ruby to Go. Doesn't mean Ruby was a bad choice, IMHO it helped you iterate faster on the initial product/prototype. I think both compiled and scripted solutions have their place in software development. What editor do you use at Github to write Go code?