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

61–66 of 66 posts

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

#61

Post by sdhgaiojfsa »

tigershark wrote: post #60
sdhgaiojfsa wrote: post #59

Earlier quoted context omitted.

> I guess that you have never worked on big systems I work on search and indexing systems at Google, and have done for more than a decade. I'm by no means the best, nor an authority. But I have spent some time living in this problem space, and this is my conclusion from my years of experience. FWIW a single run of the tests for the system I work on now takes . . . I don't know. I would guess hours or maybe even a day…

In the real world you don’t have pretty much unlimited resources. If I remember correctly those tests I was speaking about were already running in parallel on 2 or 3 machines otherwise the total time would have been 2 or 3 times more. Obviously we couldn’t use hundreds of machines to make them run in 10 minutes. In most of the places were I worked even getting a couple of new machines for production use would take mo…

> In most of the places were I worked even getting a couple of new machines for production use would take months

OK, well I guess this would be another caveat for my advice. If bringing up a production simulacra would take more resources than you have, then you might have to lean more on various types of doubles. This may be more often in environments that have insane prioritization of dev time vs. machine resources.

If I may ask, what was the bottleneck in your test suite? Did it saturate the cpu, ram, disk?

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

#62

Post by latchkey »

lobster_johnson wrote: post #38
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…

The weird thing is if you -add a dependency before you import it, then you get a warning that the dependency isn't used in the codebase yet. Of course it isn't, I just added it! My IDE (IDEA) resolves the imports for me, so I can't add the import until after I add the dependency. Nice little catch-22.

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

#63

Post by tigershark »

sdhgaiojfsa wrote: post #61
tigershark wrote: post #60

Earlier quoted context omitted.

In the real world you don’t have pretty much unlimited resources. If I remember correctly those tests I was speaking about were already running in parallel on 2 or 3 machines otherwise the total time would have been 2 or 3 times more. Obviously we couldn’t use hundreds of machines to make them run in 10 minutes. In most of the places were I worked even getting a couple of new machines for production use would take mo…

> In most of the places were I worked even getting a couple of new machines for production use would take months OK, well I guess this would be another caveat for my advice. If bringing up a production simulacra would take more resources than you have, then you might have to lean more on various types of doubles. This may be more often in environments that have insane prioritization of dev time vs. machine resources.…

I don’t really remember. The software was a kind of ORM but it was built to interface the java code with an object database, so it doesn’t make much sense to call it ORM. Probably the main bottlenecks were cpu and disk if I have to guess. I arrived very late in the project, at the point where we were going to migrate everything to oracle and we had to add oracle support to that behemoth.

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

#64

Post by lobster_johnson »

latchkey wrote: post #62
lobster_johnson wrote: post #38

Earlier quoted context omitted.

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…

The weird thing is if you -add a dependency before you import it, then you get a warning that the dependency isn't used in the codebase yet. Of course it isn't, I just added it! My IDE (IDEA) resolves the imports for me, so I can't add the import until after I add the dependency. Nice little catch-22.

Good point, I dislike that behaviour, too.

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

#65

Post by codesuki »

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…

Could you give a more complete example of how that works? I had a look at the `go/ast` package but couldn't find anything.

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

#66

Post by lobster_johnson »

codesuki wrote: post #65
atombender wrote: post #34

Earlier quoted context omitted.

> 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…

Could you give a more complete example of how that works? I had a look at the `go/ast` package but couldn't find anything.

It's in ast.go (https://github.com/golang/go/blob/master/src/go/ast/ast.go). Look how Node, Expr etc. are interfaces, with concrete struct implementations. The interfaces don't do much, only provide position information.
Post reply on HN