Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go best practices, six years in (2016)

peter.bourgon.org

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Go best practices, six years in (2016)

#31

Post by sagichmal »

natethinks wrote: post #28
junkscience2017 wrote: post #10

Earlier quoted context omitted.

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

> the sort of library that excites intermediate developers 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 sch…

Opting-in to microservices has almost nothing to do with CPU efficiency.

Re: Go best practices, six years in (2016)

#32

Post by kylequest »

0xmohit wrote: post #5

50 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...

I have another post that covers a few project structure best practices: https://medium.com/golang-learn/go-project-layout-e5213cdcfa...

It has a little more than Peter's post, but it's still not too opinionated :)

Re: Go best practices, six years in (2016)

#33

Post by kylequest »

bbatha wrote: post #29

This is generally great advice, and aside from the package manager recommendations is still relevant today. I do take issue with a few things though. 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it. 2. This is just wrong: > fmt.Printf is self-contained and doesn’t affect or depend on global state; in funct…

> 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it.

It's a little too late for this because it's pretty much an unofficial standard for library code :-) Just look at Kubernetes, Docker or many other major Go-based applications/tools.

Re: Go best practices, six years in (2016)

#34

Post by atombender »

bbatha wrote: post #29

This is generally great advice, and aside from the package manager recommendations is still relevant today. I do take issue with a few things though. 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it. 2. This is just wrong: > fmt.Printf is self-contained and doesn’t affect or depend on global state; in funct…

> the functional options pattern

Functional options are controversial in the Go community. I don't like them personally. The idea of having a bunch of functions that exist only to mutate internal state on init is... an odd choice. Google code is riddled with this sort of style.

It's annoying to write client code for another reason: It's hard to discover. For the "term" example in the article, you can't sit in your editor/IDE and type "term." and get a list of setter suggestions, since everything in a single namespace. "term.Speed()" does not sound like an option to me. Function names are generally verbs, and having one called Speed() doesn't read well. And it causes issues if you want to have a type called Speed. Then it has to be term.WithSpeed() or term.SetSpeed() or something. Neither of which is really self-explanatory.

The fact that options are functions has other downsides. The moment you pack a option into a function, they've lost their ability to be introspected. You can't dump the options to a debug log before you invoke the constructor function. You can never ask an option function what it contains.

I prefer representing options using actual data:

  type (
    Option interface {
      isOption()
    }

    Speed int
    RawMode bool
    SomeOtherSetting struct {
      A, B int
    }
  )
Unfortunately, due to how Go interfaces work, you'll have to provide a dummy private method to tie the types together, but it's a small loss. (Go itself uses this pattern in a bunch of places, such as the compiler's AST.)

Re: Go best practices, six years in (2016)

#35

Post by chimeracoder »

atombender wrote: post #34
bbatha wrote: post #29

This is generally great advice, and aside from the package manager recommendations is still relevant today. I do take issue with a few things though. 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it. 2. This is just wrong: > fmt.Printf is self-contained and doesn’t affect or depend on global state; in funct…

> the functional options pattern Functional options are controversial in the Go community. I don't like them personally. The idea of having a bunch of functions that exist only to mutate internal state on init is... an odd choice. Google code is riddled with this sort of style. It's annoying to write client code for another reason: It's hard to discover. For the "term" example in the article, you can't sit in your ed…

> Functional options are controversial in the Go community. I don't like them personally. The idea of having a bunch of functions that exist only to mutate internal state on init is... an odd choice. Google code is riddled with this sort of style.

I come from a background in functional programming, and having used functional options in Go for a while now, I completely agree. I've never seen an implementation of them that felt natural or idiomatic to use. They're incredibly awkward, and I basically always prefer the alternative approaches to the functional options style.

Re: Go best practices, six years in (2016)

#36

Post by chimeracoder »

pjmlp wrote: post #14
Goopplesoft wrote: post #13

Is 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

> Well, it is on its way out, have you missed the news regarding vgo?

Dep will have a clean migration path to vgo, and the latter isn't really production-ready yet.

For now, I'd recommend using dep for daily use, until you have a compelling reason to switch to vgo, at which point the migration will probably be automatic.

Re: Go best practices, six years in (2016)

#37

Post by pokstad »

bbatha wrote: post #29

This is generally great advice, and aside from the package manager recommendations is still relevant today. I do take issue with a few things though. 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it. 2. This is just wrong: > fmt.Printf is self-contained and doesn’t affect or depend on global state; in funct…

I think `fmt.Printf` is a typo. Immediately preceding this is a code sample referencing `fmt.Fprintf` (which is correct).

Re: Go best practices, six years in (2016)

#38

Post by lobster_johnson »

Goopplesoft wrote: post #13

Is 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

We use Dep. It's good, much better than the buggy mess that is/was Glide.

My only criticism is that "dep ensure" will actually parse the code to discover dependencies through import statements, which is also what Glide does. To me, this is antithetical to the purpose of a Gopkg.toml/lock file. In other words, Dep's full list of dependencies isn't actually in the Gopkg.toml file; it's a sum of Gopkg.toml and your code. That is confusing.

My desired behaviour:

* "dep ensure" should always used the lock file, nothing else, to install;

* "dep ensure -update" should update the lock file to what is specified in Gopkg.toml (and only that);

* "dep ensure -add" (which I think should be "dep add") should b required to add new dependencies to the Gopkg.toml file.

Aside: I wish Go projects weren't stuck with BSD style flags (-update instead of --update). GNU style is more common and arguably more practical. I applaud whenever a project (e.g. Prometheus, recently) finally sees sense and goes over to GNU flags.

Re: Go best practices, six years in (2016)

#39

Post by lobster_johnson »

pjmlp wrote: post #14
Goopplesoft wrote: post #13

Is 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

vgo is at least phrased as being a proposal, not necessarily the future of Go [1]:

    This post sketches a proposal for doing exactly
    that, along with a prototype demonstration ...
    I intend this post to be the start of a productive
    discussion about what works and what doesn't.
    Based on that discussion, I will make adjustments
    to both the proposal and the prototype, and then 
    I will submit an official Go proposal, for
    integration into Go 1.11 as an opt-in feature.
Of course, this is Russ Cox, so chances are that his proposal will carry more weight with his fellow core Go team than that of Dep's authors.

Sam Boyer's follow-up is interesting reading [2]. I get the feeling that despite their ongoing discussions, the Dep team was/felt ambushed by this move.

[1] https://research.swtch.com/vgo-intro

[2] https://sdboyer.io/blog/vgo-and-dep/

Re: Go best practices, six years in (2016)

#40

Post by discoursism »

atombender wrote: post #34
bbatha wrote: post #29

This is generally great advice, and aside from the package manager recommendations is still relevant today. I do take issue with a few things though. 1. Don't put your internal libraries in /pkg. /pkg has special GOPATH meaning as "compilation cache". Its not an actual name conflict, but why bother risking it. 2. This is just wrong: > fmt.Printf is self-contained and doesn’t affect or depend on global state; in funct…

> the functional options pattern Functional options are controversial in the Go community. I don't like them personally. The idea of having a bunch of functions that exist only to mutate internal state on init is... an odd choice. Google code is riddled with this sort of style. It's annoying to write client code for another reason: It's hard to discover. For the "term" example in the article, you can't sit in your ed…

My biggest object to the functional options argument is the step where

    NewServer(..., Config{})
is considered bad for some reason. As far as I can tell, the entire purported utility of the thing is based on avoiding this obvious approach.
Post reply on HN