Pretty good advice, except the preference for interfaces to support mocking. You should avoid mocking when possible in favor of real objects or fakes. Interfaces are still cool, though.
Go best practices, six years in (2016)
11–20 of 66 posts
Re: Go best practices, six years in (2016)
#12Here are also some Go proverbs. Some of them are a lot older than 6 years. https://senseis.xmp.net/?GoProverbs
Re: Go best practices, six years in (2016)
#13Is anyone else using golang dep[1] as their vendor/dependency tool?
I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often.
Re: Go best practices, six years in (2016)
#14Is anyone else using golang dep[1] as their vendor/dependency tool? I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often. [1] https://github.com/golang/dep
Well, it is on its way out, have you missed the news regarding vgo?
Re: Go best practices, six years in (2016)
#15Rule of thumb: anyone using the term "best practices" doesn't understand them.
(Yes, some do. On the whole I find most don't.)
Re: Go best practices, six years in (2016)
#16Pretty good advice, except the preference for interfaces to support mocking. You should avoid mocking when possible in favor of real objects or fakes. Interfaces are still cool, though.
Can you explain this further, or offer a link that does?
Re: Go best practices, six years in (2016)
#17Rule of thumb: anyone using the term "best practices" doesn't understand them. (Yes, some do. On the whole I find most don't.)
Are you saying that speaks on this article or not? I don't care about a rule of thumb if it doesn't apply here.
Re: Go best practices, six years in (2016)
#18Is anyone else using golang dep[1] as their vendor/dependency tool? I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often. [1] https://github.com/golang/dep
Well, it is on its way out, have you missed the news regarding vgo ? https://research.swtch.com/vgo
Er, thanks. We've just moved to go dep :)
Go's dependency management story is starting to resemble JS's modules story :(
Re: Go best practices, six years in (2016)
#19Is anyone else using golang dep[1] as their vendor/dependency tool? I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often. [1] https://github.com/golang/dep
Yes using dep full time for projects andnit has been great.
I think it’s the right choice for now. It was going to be the one true solution and many people have stopped working on the alternatives.
We’ll see where vgo lands, but dep is very practical right now.
Re: Go best practices, six years in (2016)
#20Earlier quoted context omitted.
Well, it is on its way out, have you missed the news regarding vgo ? https://research.swtch.com/vgo
Er, thanks. We've just moved to go dep :) Go's dependency management story is starting to resemble JS's modules story :(
Yeah... In defense of the Go folks (1) they are working hard to make the transition as smooth as possible (2) dep was always just considered an experiment (though with aspirations by the author to have it become the official solution) (3) vgo almost certainly marks the end of the churn, and looks really nice.