Go best practices, six years in (2016)
peter.bourgon.org
Go best practices, six years in (2016)
1–10 of 66 posts
Re: Go best practices, six years in (2016)
#2This is great, but I wish it would get updated for 2018 as it is now 2 years old.
Re: Go best practices, six years in (2016)
#3This is great, but I wish it would get updated for 2018 as it is now 2 years old.
Search for "update:" in the article. There are three and the most recent references a post from June of 2017. It appears the author has modified it for developments he considers important. It would be helpful if he indicated the revision date near the top of the article.
Re: Go best practices, six years in (2016)
#4Author of go-kit microservices framework, which has several nice examples with which to get up and running
Another interesting recent project is Truss which allows you to autogen go-kit handlers from protobuf definitions
Re: Go best practices, six years in (2016)
#550 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs [0] might serve as a nice supplement to this article.
[0] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
Re: Go best practices, six years in (2016)
#6I love the way the headings and their 'anchors' are styled on this blog post. I don't know, it just looks so pleasing.
Re: Go best practices, six years in (2016)
#7[2016]
Re: Go best practices, six years in (2016)
#8Author of go-kit microservices framework, which has several nice examples with which to get up and running https://gokit.io/examples/ Another interesting recent project is Truss which allows you to autogen go-kit handlers from protobuf definitions https://github.com/TuneLab/truss/blob/master/TUTORIAL.md
I found Gokit's stringsvc tutorial particularly helpful: https://gokit.io/examples/stringsvc.html
Re: Go best practices, six years in (2016)
#9At [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.
Re: Go best practices, six years in (2016)
#10At [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 fantast…
I feel like go-kit is quite antithetical to the Go mindset...it presents a lossy abstraction as a means of future-proofing against eventualities that will almost certainly never be encountered
to be honest it strikes me as the sort of library that excites intermediate developers who tend to over-architect