HashiCorp put out good stuff. CoreOS can be hit or miss; Torus was nice, etcd is a wreck. I like https://github.com/go-kit/kit and https://github.com/oklog/oklog. Definitely avoid Kubernetes and Docker -- they're Go by committee, look and feel like transliterated Java.
I'm flattered. If you like the Torus style, https://github.com/coreos/go-tcmu is a package I'm quite proud of (SCSI interactions wrapped in a nice pure-Go interface) and then a plug for https://github.com/cayleygraph/cayley which is a little rougher but a nice community and large codebase I maintain.
Seconding the Hashicorp projects. I learned a lot about HTTP from reading the Vault code.
go-kit and oklog are also fantastic. Peter Bourgon has written a good article about Go best practices and his open source projects really aim for clean, readable code.
I know very little Go, but I have seen the Kubernetes code and my impression was "I bet these people were Java programmers in a past-life". You could tell by the multiple layers of abstraction, a lot of which felt unnecessary.
Having said that, Kubernetes is a solid piece of engineering, so they are clearly doing something right and I don't want to denigrate their hard work.
Kubernetes also came from the same engineers that worked on Borg (Google's internal Kubernetes), which is written in C++. I imagine a lot of the constructs and design/layers were inspired by their experience in Borg.
Some of the style adopted for Kubernetes mirrored both previous Java experience (inside Google and out), but most of it was simply observation of other large Go codebases.
I don't think much of the layering / structure has anything to do with Borg except in a few areas:
1. Scheduler predicates
2. The massive ball of yarn that the kubelet started off as and was unable to achieve escape gravity on (until CRI landed)
Everything else was focused on pure efficiency and is only slightly biased by general experience building large software projects (pass dependencies down, avoid complicated abstractions, rigorous style enforcement). A lot of that leaked as Kube grew into a larger and larger community and more people contributed.
The other abstractions people complain about mirror traditionally hard problems (API version stability with conversion across semantic changes, general API surface area management). Other than that we decided not to build on relational stores but a partitioned document model (etcd, inspired by chubby, but not fundamentally different from any other object store), I'd say the code is mostly just a reflection of being good enough to maintain now and refactor later. Pretty code is easy when it's a few people writing it. Harder when it's a team of tens / hundreds
> Pretty code is easy when it's a few people writing it. Harder when it's a team of tens / hundreds
Yeah, this is a good point that I was overlooking. It's easy for me to be critical when I feel the pain digging through multiple levels of abstraction to find out how something works, but I didn't the feel the greater pain of trying to manage tens or hundreds of developers working on the same codebase.
