Love Go. But this is yet another case where language creators opted out of standardizing something they should have. The community is left to fend for themselves and squabble over naming conventions and boilerplate.<p>The golang-standards/project-layout repo is the inevitable outcome. An over-engineered land grab (let's call it what it is). But 11k stars is a decent indicator of Go programmers wanting some kind of authoritative standard so they don't need to re-organize their now-small but tomorrow-large projects over and over.<p>A recent issue that parallels this one is package management. So many monstrosities came out of that until go modules was formalized :P
My advice is to not overthink it and do what works for you.<p>IMO,<p>don’t use a pkg directory. It only makes your import paths more unwieldy.<p>Don’t use internal unless you have a package that is an awkward implementation detail that must be shared between packages for expedience. Usually this can be factored away with some effort but sometimes it’s not worth it.<p>Do use cmd directories. They make it clear what “go install” will do.<p>But otherwise really just pick any approach and move on with your life.
I like the use of pkg/ as it allows you to separate your source code from other things that might be in the repository such as a README, LICENSE, Dockerfile, Makefile, linter configurations, go version configuration, etc. These things usually live in the root of the repository so you know to look for them there but if you also have your source code there it makes things harder to find.<p>This is also one of the reasons why some other programming languages might have adopted the standard of src/ or lib/.
> Most people who would bother with the matter at all would admit that the layout of Go projects is in a bad way.<p>... How? They just don't tell you that files have to be under a certain directory. It's beyond me how that upsets people.<p>I think this is just people looking for something to argue about. The go team can't standardize <i>everything</i>.
Somehow the text was hard to read / follow for me. Might be because I'm a bit tired though.<p>Anyway, OT: Even though there might not be an "official" standard, there is indeed a community standard.<p>If I explore other projects I hope to see some common structures reflected there, which makes it easier to browse the code.
I personally use a pkg directory because I like an uncluttered root and don't want to end up at some point having a namespace collision with something that would be better placed in the root directory.