OVovao·Aug 6, 2017
> 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 wrap
Read the rest
per, 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.