Ask HN: Good Go codebases to read?
There was a similar post about Python a couple of years ago (https://news.ycombinator.com/item?id=9896369) and it helped me tremendously. I'm looking for something similar with Go.
Thanks!
There was a similar post about Python a couple of years ago (https://news.ycombinator.com/item?id=9896369) and it helped me tremendously. I'm looking for something similar with Go.
Thanks!
https://sourcegraph.com/github.com/golang/go/-/blob/src/net/... https://sourcegraph.com/github.com/mholt/caddy@master/-/blob... https://sourcegraph.com/github.com/btcsuite/btcd@master/-/bl... https://sourcegraph.com/github.com/camlistore/camlistore@mas... https://sourcegraph.com/github.com/boltdb/bolt@master/-/blob... https://sourcegraph.com/github.com/go-kit/kit/-/blob/example...
`git clone https://github.com/golang/go` then `cd go`, and `tree .`, `git grep ...`, `vim ...`, etc.
Anyway, couldn't find how to get the tests to pass, but found this:
https://golang.org/doc/codewalk/markov/
And a little explanation: https://golang.org/doc/codewalk/codewalk/
Also: https://golang.org/doc/install/source
In terms of codebase, kubernetes and upspin seem pretty good too:
https://github.com/kubernetes/kubernetes https://github.com/upspin/upspin
But yes having a global namespace is a genius idea.
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.
Also join the go slack if you haven't yet.
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.
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
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.
Bolt (also here mentioned) is one of my favorite beautiful codebases. https://github.com/mdlayher is a prolific author with lots of good protocol implementations. https://github.com/chihaya/chihaya is a fun project if you're into BitTorrent.
In contrast, I've worked in places where I needed a drink or 3 before I can build up the gumption to open my text editor :-)
https://github.com/fogleman?utf8=&tab=repositories&q=&type=&...
As others have suggested, looking through go's std library is a good idea as you will need to be familiar with it in any case. Use https://golang.org/pkg/ liberally to go from reading API documentation to code.
Look at https://golanglibs.com categories and pick the one that interests you or is something you already know a bunch about. Then pick something simple from that category.
There is a library that converts some python libs to go packages. This may also help as you can see how the mapping worked.
Finally, just pick up the Go book and start coding something you care about! Go's online documentation is quite good. I was able to bootstrap 3 high-school interns this way fairly well and they actually produced a fair bit of working code in 7 weeks. IMHO you should spend a significant part of your "study" time writing code. Read other code as and when you need it.
Also would like to hear feedback if you spot something which doesn't seem pretty/idiomatic in my code.
https://commandcenter.blogspot.com/2014/01/self-referential-...
I'd really like to see more examples of these types of codebases but can't seem to find examples anywhere.
Otherwise, the standard library is always a good way to find out about things that you didn't know existed, or forgot after reading the standard.
https://github.com/jmoiron/sqlx https://github.com/go-kit/kit
https://github.com/tidwall/buntdb https://github.com/tidwall/tile38
Many of what is now the Go standard lib came from Brad Fitzpatrick's work on Camlistore.
William is one of the Authors of "Go in Action" and a great teacher.