Hacker News Reader

Comment by jclulow | Hacker News Reader

> Too many people have a bad habit of including “go” in their repository name, presumably to not confuse people with non-go version of the code.

Note that this is actually a perfectly reasonable thing to do. If I had two clients for some particular API, one written for Node and one for Go, it absolutely makes sense to name them "node-whatever.git" and "go-whatever.git".

Part of what makes naming things hard is needing to come up with a more "creative" name for every little module, especially once you throw in the constraint that apparently eight characters is too long and four characters is just right.

View on HN

It might be necessary to resolve naming conflicts but it's not good.

In Go, package name should be the same as repo name.

Most cases that I've seen are not including "go" in repo name to resolve naming conflict but "just because", possibly cargo-culting others that did it.

What if those people or organisations have a lot of repositories and they want to use a naming convention that reflects that maybe, just maybe, only a subset of their code is written in Go?

I recognise that you don't speak for the entire Go community, but frankly this kind of over-prescriptive preference presented as the only possible way forward is oddly common in what often seems more like a church than a programming language ecosystem.

Go is just a tool, like any other. If I happen to use git for versioning that's my choice, and I (and everybody else) can and should name and arrange repositories as is convenient.

There is no "in Go" to be had here; merely "in my project as makes sense for me".

> What if those people or organisations have a lot of repositories and they want to use a naming convention that reflects that maybe, just maybe, only a subset of their code is written in Go?

I'm not sure I understand how that's an argument in itself for using "go-" or "-go" (or some other version) in a package name. It results in a lack of clarity in how to reference the package: the hypothetical "github.com/stripe/stripe-go" import path probably (and almost certainly) introduces the "stripe" package name, but the the discordance between what you write as an import statement and by what name the package is referenced is unconventional and strange.

There are certainly times when it makes sense. And I agree with the idea that an organization, in most cases, shouldn't come up with a unique name for the Go implementation of, say, an API wrapper, just to satisfy Go convention. But generally speaking the convention should be followed not simply because it's prescribed but because it's sensible to avoid that disconnect between the import statement and the package name.

If you must then you must.

I'm not sure if you actually disagree with me.

Like I said, most of the time I see "go" in project name, it's not because the owner of the repo was in the hypothetical situation you describe.

So unless you think it's ok to add "go" to the name of the repo willy-nilly there's no disagreement.

> In Go, package name should be the same as repo name.

First of all, it's entirely possible that "go" is in the repo name, but beyond that, I regularly see packages (and very popular, mainstream packages) where the package name is not the repo name. The one that comes to mind is github.com/mattn/go-sqlite3 which provides the `sqlite3` package.

Every package dependency should be installed in /usr/lib by the admin or else vendored in our repo using its canonical import path. It's a mistake for "go get" not to do this by default, because the compiler shouldn't even be aware of the name of the repo we got the code from.

The compiler doesn't care. Even for the build tool it doesn't really matter. The one thing that cares about repositories is "go get", a small convenience wrapper around git/hg/svn.

> possibly cargo-culting others that did it.

Agreed, I don't see the point of mentioning the language for compiled, stand-alone programs and standard, C-compatible libraries. The resulting binary is the same (well, of the same nature at least) whichever language it was compiled from.

It only has a use for programs and libraries in interpreted (in the widest sense of the word) languages, which can only be used together with libraries in the same language, or from programs in the same language, or with a specific external runtime or virtual machine.

Reply on news.ycombinator.com