Hacker News Reader

Comment by wtbob | Hacker News Reader

Good article on the whole, but I have a few quibbles:

> If your repo foo is primarily a binary, put your library code in a lib/ subdir, and call it package foo.

IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo.

I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/.

I think that inline config objects should be used with useful zero values to try to emulate Lisp's or Python's keyword arguments: if one always needs to provide a value for each config object member, then just use arguments after all.

I think a testing library can be a great addition, since it can turn a three-line if check into a one-line assertion.

View on HN

> IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo. > I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/.

It's this kind of inflexibility in the directory structure of ones repo that really turned me off of Go. It's such a trivial thing, and yet the fact that Go lacks a level of indirection (package.json, Cargo.toml, pom.xml, etc) to map a chosen directory structure to the standard build tooling causes problems that get really annoying. For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make. And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code lives at the repository root" doesn't play well with others.

It all makes me sad since Go's decentralized dependency management (i.e. go get being able to pull/build based on a meta tag) is brilliant and I always hate having to rely on a single, centralized repository to deal with dependencies.

> For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make.

Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him …

> And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code lives at the repository root" doesn't play well with others.

I've actually built libraries which involved both Go & Python without a problem.

> Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him …

Yes, there are. I don't know any off the top of my head, but I see them all the time. So, just for fun, how about a little test:

Step 1: Google 'notable applications written in golang'

>> first result: http://www.infoworld.com/article/2843821/application-develop...

Step 2: Click through to github repos

>> Result 9/10 of them won't work with go get.

So, are Docker, Kubernetes and Etcd the kind of software you wouldn't want to run because their creators are too ignorant of the language?

The etcd binaries are go gettable. The others are large enough to easily justify their own build process.

> I think a testing library can be a great addition, since it can turn a three-line if check into a one-line assertion.

Totally concur with this. I feel like all these people complaining about "bloated test frameworks" either haven't written a lot of tests, or are just fine with repeating themselves in test code, or they end up writing their own version of a test framework anew in every project. So much simpler and sane to grab an off the shelf solution for test code.

Reply on news.ycombinator.com