Let's please not upvote this. It is _not_ a "standard" go project - it doesn't even have a go.mod. Furthermore, it is in an org called "golang standards", when in reality it and its projects are not standards - they're just some opinions of some programmers.
Let's please not make getting started with golang more confusing to beginners by falsely claiming standards.
Although I respect that this shouldn't be confused as a standard, as a Go beginner with some very small attempts at creating Go projects[1] I would appreciate some sort of guidance on organizing code for a larger project. I've considered rewriting some of my larger NodeJS side projects in Go and I, possibly misguidedly, feel like the biggest barrier to entry is understanding the correct way to organize everything (i.e. directory structure). Is there any documentation, tutorials, anything that you or others would recommend for larger Go projects?
I'm curious - what you feel is specifically the barrier? Which parts of your Node project you want to port to Go and don't because you don't know where to put them?
While I do agree that this particular case may have some issues I still think that having a good starting point for people newly introduced to the ecosystem is invaluable.
Cookiecutter's pypackage repo [0] isn't necessarily standard either but it does provide a lot of helpful boilerplate and 'best-practices' that are hard to integrate after the fact.
Creating massive "this is how you do it" template repos to show everyone how smart you are is grating. The assumption that everyone needs everything and the kitchen sink and want to use your architecture abstraction is incredibly misguided.
I've used Golang successfully on a few projects and this is completely unparseable.
This is in no way the standard go project layout - this is one repository with umpteen folders containing almost no information. This is more to confuse than it is to help new developers.
6 comments
[ 12.0 ms ] story [ 262 ms ] threadLet's please not make getting started with golang more confusing to beginners by falsely claiming standards.
Also, see numerous similar complaints in this project's issue tracker: [ex1 https://github.com/golang-standards/project-layout/issues/38) [ex2 https://github.com/golang-standards/project-layout/issues/38].
[1]
https://github.com/whatl3y/argv
https://github.com/whatl3y/cdd
https://github.com/whatl3y/odds
Cookiecutter's pypackage repo [0] isn't necessarily standard either but it does provide a lot of helpful boilerplate and 'best-practices' that are hard to integrate after the fact.
[0] https://github.com/audreyr/cookiecutter-pypackage
Creating massive "this is how you do it" template repos to show everyone how smart you are is grating. The assumption that everyone needs everything and the kitchen sink and want to use your architecture abstraction is incredibly misguided.
I've used Golang successfully on a few projects and this is completely unparseable.