Finally, there is an official document with recommended ways to structure your Go project.<p>To be honest, it's really minimal and liberal but that is definitely better than what is by an unfortunate name collision considered the official Go layout now.
Compare and contrast this with the Go Standards project-layout repo example[1] - which ironically is not a standard at all.<p>Personally I prefer a bit more rigidity in how the project is structured (/pkg/, /pkg/internal/, /cmd/) since it is more opinionated and requires less thinking. Typically my repos won't just have a Go backend but also a frontend too, and supporting assets, as well as documentation (designs, decisions, etc.)<p>[1] <a href="https://github.com/golang-standards/project-layout">https://github.com/golang-standards/project-layout</a>
I knew it reminded me of something! Eli Bendersky's post <a href="https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/" rel="nofollow noreferrer">https://eli.thegreenplace.net/2019/simple-go-project-layout-...</a> now starts with "Update (2023-09-19): We've now published similar guidelines as part of Go's official documentation. This blog post will remain up-to-date." I've learned a lot about Go from this website.
Questions left unanswered:<p>- When are go multi-module workspaces best used?<p>- What should you use for the module-path argument to `go mod init` if you don't ever intend to share the repo or you don't yet know where you will be sharing it?