project-layout

> https://github.com/golang-standards/project-layout The name of the repo is really and intentionally misleading. rsc filled an issue there to point this out, but the repo maintainer just disabled issues altogether so now no one can see it. Even when it would not have such parasitic name, many seasoned Go programmers, me included, consider the self-proclaimed "Standard Go project Layout" as the opposite of what is good and advisable. Unfortunately, the name just works, so it is being recommended all over the Internet since its inception.

To be honest, the best method is to find good Go libraries and do some code reading. Not every project will be using best practices, even those created by prominent Go developers, but if you read through several libraries, you'll pick things up by osmosis. That said, https://go.dev/doc/modules/layout and https://github.com/golang-standards/project-layout may help.

Your comment makes it look as if you're saying you hate the Go development team, but it seems that isn't the case. I get a little of what you're saying, I wouldn't say I hate anyone, but I strongly dislike how a lot of projects are organized. I think a lot stems from https://github.com/golang-standards/project-layout , which pretended to be standard and was so (ab)used one of the creators opened an issue about it. If you look at the actual Go src, it's much, much cleaner.

Compare and contrast this with the Go Standards project-layout repo example[1] - which ironically is not a standard at all. 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.) [1] https://github.com/golang-standards/project-layout

Assume you know about this https://github.com/golang-standards/project-layout/issues/11... We could ignore this repo and construct our own project structure based on our requirements.

This is not a standard as a member of the Go team also pointed out: https://github.com/golang-standards/project-layout/issues/11.... Doesn't mean this can't be useful, just not a standard. And though it's a "community effort", it's not supported by the Go community as a whole. Quite far from it, it's primarily one person's efforts and at least publicly that individual is the only member of the golang-standards org. The whole "golang-standards" namespace is a bit iffy, it lends it more legitimacy than it has.

The thing now I see in the Go community is cargo culting coming from seasoned veterans who took advantage of Go's minimal set of rules and created their own "standards". Take this project in Github called golang-standards. It even got the attention of Russ Cox who dismissed it in this Github issue: https://github.com/golang-standards/project-layout/issues/11....

This pattern or close variants or subsets are fairly common: https://github.com/golang-standards/project-layout

Damn. > https://github.com/golang-standards/project-layout I was almost with you but please don't share that repo. It's a terrible layout and the docs aren't accurate. The issues are full of Go community folk saying it's misleading and looks official but isn't.

>What I would really like is an up to date "learn how to handle Go project in 30 minutes" 1. git init 2. git remote add %something% 3. go mod init %name_of_your_module% (where in most common case name is your repo address without the https part) 4. https://github.com/golang-standards/project-layout - this repo has the default project structure. Each subfolder has README that describes the purpose of the folder 5. go get -u github.com/gin-gonic/gin to add gin (web lib) for your project. Same for any other package. The will be added to your go.mod and go.sum files 5.1 import "github.com/gin-gonic/gin" in your code to use gin 5.2 package may have more than one major version (tag). If you want to use package at latest tag 2 - you add '/v2' when you 'go get' the package (i.e. go get -u github.com/gin-gonic/gin/v2) 6. git commit && git push to

Just a tip for those looking at trying out Go (and the author of the post): this repository, https://github.com/golang-standards/project-layout, is NOT an official or standard Go folder structure. It's not necessarily bad, but it shouldn't be seen as Go's default folder structure. Too many newbies have gotten tripped up by the name.

In Go, there's a standard project layout [1]. It'd be nice to have a project layout linter in Go Report Card [2]. [1]: https://github.com/golang-standards/project-layout [2]: https://goreportcard.com