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.)
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.
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.)
[0] https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be [1] https://www.ece.rice.edu/~willmann/teng_nics_overview.html
On the other, more modular side, try something like the Gorilla toolkit e.g. https://github.com/gorilla/mux/
I'll be honest, I rarely use channels other than for timeouts/deadlines.
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.
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.
Go-routines are quite ubiquitous especially in server-style projects.
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.