7 ms·

What are some examples of medium-large Go projects where the code is well-written? By that, I mean code that would make a good example for someone trying to lea

What are some examples of medium-large Go projects where the code is well-written? By that, I mean code that would make a good example for someone trying to learn the "right" way to do things. I was briefly learning Go a while back. I'm curious how well gorotuines and channels have held up as building blocks, and how extensively they are used in real projects.

benhoyt 6y ago
These days when I see a fast, reliable CLI tool I think "this has got to be written in Go" and a lot of the time they are. Some examples: the new GitHub CLI, Docker, Hashicorp tools, ngrok (though v2 is not open source), Caddy, the list is quite long. I can't vouch for the quality of that code, but I suspect some of those projects are good starting points. And I've found the Go standard library source to be really helpful (and generally fairly easy to understand).
- megameter 6y ago
  Speaking from some experience, Go is probably the best option these days at "do one thing well" command line tools - the mix of library support, native binaries, and the simple, stable language make it a good fit for a weekend project that opens files, munges strings and pushes them over standard protocols. When Go has to support a large application that defines a platform in itself, the downsides of the language rise to the forefront, but that level of expression usually isn't entailed in a Unix-style CLI tool. (Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat.)
  - majewsky 6y ago
    > Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat. When you have a CLI for some network-based service, the network latency is going to be magnitudes larger than the performance differences between Go and Rust anyway. (Or at least in 99% of cases.)
    - tonto 6y ago
      some suggestions are that in the future, the I/O latency is going to get very low, network speeds very fast, etc. [0] https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be [1] https://www.ece.rice.edu/~willmann/teng_nics_overview.html https://www.ece.rice.edu/~willmann/teng_nics_overview.html
      - majewsky 6y ago
        Unless that 10-gig NIC messes with the speed of light, I don't see it reducing the RTT between me and some server in the US by any significant amount.
  - CogitoCogito 6y ago
    One thing I hate is that the go flags package sorts the options by default. Ordering options in a thoughtful way is definitely a plus in an api. I know there are (not very intuitive) ways to override this, but I just can't understand why they would make such a bizarre choice even given their penchant for being opinionated. edit: Now that I read this over, this complaint seems a bit misplaced in this thread, but I guess I'll leave it due to its sort of relation to cli programs in go.
- akoncius 6y ago
  not sure about docker/kubernetes. I've read somewhere that after investigation of source code there were conclusions that source code is not using good practices, a lot of duplication of code and so on thus making conclusion that project has some risks in technical debt or something like that. Would not be good to learn from project which is not well written :)
hactually 6y ago
It depends on what you want - big side of things, check out docker/Moby though it's a little hard to follow due to their approach on using Docker to build, maybe Terraform? On the other, more modular side, try something like the Gorilla toolkit e.g. https://github.com/gorilla/mux/ https://github.com/gorilla/mux/ I'll be honest, I rarely use channels other than for timeouts/deadlines.
3fe9a03ccd14ca5 6y ago
> By that, I mean code that would make a good example for someone trying to learn the "right" way to do things. You’re in luck! Go is unlike a lot of other languages, and that there’s usually only one way to do something, and it’s usually the right way, or at least an acceptable way. I would suggest you just pick a part of the standard library, such as net/http and just read away since you probably have an understanding of the fundamentals.
cube2222 6y ago
Prometheus is a very readable and understandable code base which does use those building blocks.
codegladiator 6y ago
You can probably checkout his code https://github.com/tj/ https://github.com/tj/
maxrobot 6y ago
Go-ethereum
dilyevsky 6y ago
Kubernetes (although there are some shenanigans with codegen), Cockroach DB and CoreDNS come to mind. There’re lots really - the language makes it hard not to do it “right” way. Go-routines are quite ubiquitous especially in server-style projects.
preommr 6y ago
Its remarkable how many go projects are very simple and small. I don't think its worth going through other go projects to learn best practices because at that level, there's not enough complexity to learn anything that isn't painfully obvious. There aren't really a lot of design patterns or clever tricks to learn.

benhoyt 6y ago

These days when I see a fast, reliable CLI tool I think "this has got to be written in Go" and a lot of the time they are. Some examples: the new GitHub CLI, Docker, Hashicorp tools, ngrok (though v2 is not open source), Caddy, the list is quite long. I can't vouch for the quality of that code, but I suspect some of those projects are good starting points. And I've found the Go standard library source to be really helpful (and generally fairly easy to understand).

megameter 6y ago
Speaking from some experience, Go is probably the best option these days at "do one thing well" command line tools - the mix of library support, native binaries, and the simple, stable language make it a good fit for a weekend project that opens files, munges strings and pushes them over standard protocols. When Go has to support a large application that defines a platform in itself, the downsides of the language rise to the forefront, but that level of expression usually isn't entailed in a Unix-style CLI tool. (Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat.)
- majewsky 6y ago
  > Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat. When you have a CLI for some network-based service, the network latency is going to be magnitudes larger than the performance differences between Go and Rust anyway. (Or at least in 99% of cases.)
  - tonto 6y ago
    some suggestions are that in the future, the I/O latency is going to get very low, network speeds very fast, etc. [0] https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be [1] https://www.ece.rice.edu/~willmann/teng_nics_overview.html https://www.ece.rice.edu/~willmann/teng_nics_overview.html
    - majewsky 6y ago
      Unless that 10-gig NIC messes with the speed of light, I don't see it reducing the RTT between me and some server in the US by any significant amount.
- CogitoCogito 6y ago
  One thing I hate is that the go flags package sorts the options by default. Ordering options in a thoughtful way is definitely a plus in an api. I know there are (not very intuitive) ways to override this, but I just can't understand why they would make such a bizarre choice even given their penchant for being opinionated. edit: Now that I read this over, this complaint seems a bit misplaced in this thread, but I guess I'll leave it due to its sort of relation to cli programs in go.
akoncius 6y ago
not sure about docker/kubernetes. I've read somewhere that after investigation of source code there were conclusions that source code is not using good practices, a lot of duplication of code and so on thus making conclusion that project has some risks in technical debt or something like that. Would not be good to learn from project which is not well written :)

hactually 6y ago

It depends on what you want - big side of things, check out docker/Moby though it's a little hard to follow due to their approach on using Docker to build, maybe Terraform? On the other, more modular side, try something like the Gorilla toolkit e.g. https://github.com/gorilla/mux/ https://github.com/gorilla/mux/ I'll be honest, I rarely use channels other than for timeouts/deadlines.

3fe9a03ccd14ca5 6y ago

> By that, I mean code that would make a good example for someone trying to learn the "right" way to do things. You’re in luck! Go is unlike a lot of other languages, and that there’s usually only one way to do something, and it’s usually the right way, or at least an acceptable way. I would suggest you just pick a part of the standard library, such as net/http and just read away since you probably have an understanding of the fundamentals.

cube2222 6y ago

Prometheus is a very readable and understandable code base which does use those building blocks.

codegladiator 6y ago

You can probably checkout his code https://github.com/tj/ https://github.com/tj/

maxrobot 6y ago

Go-ethereum

dilyevsky 6y ago

Kubernetes (although there are some shenanigans with codegen), Cockroach DB and CoreDNS come to mind. There’re lots really - the language makes it hard not to do it “right” way. Go-routines are quite ubiquitous especially in server-style projects.

preommr 6y ago

Its remarkable how many go projects are very simple and small. I don't think its worth going through other go projects to learn best practices because at that level, there's not enough complexity to learn anything that isn't painfully obvious. There aren't really a lot of design patterns or clever tricks to learn.