At [Kolide](https://kolide.com/) we're heavy users of Go Kit, and as a result have also adopted a lot of the style Peter recommends here. We've been slowly expanding on it with a style guide and company specific set of common libraries [here](https://github.com/kolide/kit#kolide-kit). My coworker also wrote a [blog post](https://blog.kolide.com/using-go-for-scalable-operating-syst...) on how Go has been fantastic for us and references the above style guide.The code from go kit and [oklog](https://github.com/oklog/oklog) are great examples of idiomatic Go.
Unfortunately the community at large doesn't really follow the "no init"/"no package global vars", which can sometimes lead to bad experiences importing opensource Go libs.
junkscience2017|8 years ago
to be honest it strikes me as the sort of library that excites intermediate developers who tend to over-architect
sagichmal|8 years ago
alpeb|8 years ago
lima|8 years ago
natethinks|8 years ago
I find this true about nearly all microservices in Go. Microservices are much more useful in something like Node that can only take advantage of 1 OS thread per instance. Without containerization and load balancing in Node you wouldn't be able to scale.
Go on the other hand can efficiently utilize a nearly unlimited amount of threads as necessary with its scheduler. You're much more likely to over-architect if you don't keep this capacity in mind.