this is not a standard Go project layout #117
Comments
|
@rsc could you please share a few links to some trustworthy (from your point of view) resources to learn more about the best practices for writing "idiomatic " Go code? Thank you in advance. |
This comment was marked as abuse.
This comment was marked as abuse.
|
@henvic the reason I ended up here asking for links is that I've seen many developers referring to this repo as if it has some official status, but it seems to be very questionable in a way it relates to the core ideas behind Go's creation. I'll go through those resources and your help is much appreciated. |
|
What @rsc describes here is a problem I observed many times. I saw many projects trying to "fix" their layout based on what's provided as a reference here. It creates confusion and conflict among contributors. The project is doing a good job having a disclaimer in the README, but it doesn't seem to be effective because many people don't read the text and assume this is an officially endorsed project. |
|
I am 100% aligned with both @rsc and @rakyll on their comments. We experience the same misconception about the status of this repository in the Slack workspace, especially for those who are new to the language and are trying to figure out how to do things "right". I am not sure that I get a sense, at least in our space, that it's getting any worse, but it's frequent enough that I would be comfortable classifying it as a problem. Considering the feedback being given in this issue, @kcq how would you feel about moving this repository out of the current Organization and onto a different one (or your username) to benefit the larger Go community? I'd actually be happy to provide your repo as a resource for Gophers if it wasn't asserting itself as a standard. Edit: I had forgotten I filed this awhile back, regarding the pkg/ directory: #10 |
|
I usually point people to https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/, and have done so in several issues in this very repo. You've had several long-time gophers and a couple of go maintainers chime in now. It would be really great if you could archive this repo or, at the very least, move it to a less-misleading org. I don't like saying it, but overall community impact is negative at this point. It's hurting more than helping. |
|
The issue is the different requirements between a simple system package (which I tend to think the Go team over optimizes for) and more complex apps and services. Every company I've worked at that had larger apps written in Go has a repo that looks very similar to this. Even the pkgsite repo uses some of the structure that this repo recommends. Obviously I would not use this structure for a small system library that isn't meant to be used in a standalone way but in my experience a lot of what this repo recommends is very valid and preferred for large apps. |
|
I think the primary issue is that the org is titled Differing requirements is certainly a thing to be aware of, but they're impossible to capture in a single directory hierarchy, and that's part of the problem. This repo is complex and, despite periodically stating that features are optional in documentation, has a monolithic structure which comes across as prescriptive. This is at odds with the language, IMO. Go is a relatively simple language to get started with, and this is not a good jumping off point. I've personally helped several developers rekindle their waning interest by showing them a simpler way to lay out their code. I'm sure many other folks in community forums have had similar experiences. For those that do persist, as mentioned above, they often cause further confusion by directing others to follow these guidelines in the form of PRs, issues, or just well-intentioned advice the recipient doesn't know any better about. It would be really great if at the very least the org name could change. For the reasons discussed above, this is not a very good standard, much less the standard. |
|
I am in support of the idea this project represents, but these conversations bring up one thing to me. Why doesn't something like this get published by the Go team. It doesn't have to be complex, but I feel like there is a gap in the documentation that this repo partially fills. I stumbled on this when I was in search of this information, and it was extremely helpful. I'm well past this point in my learning of Go, but I have to assume others could benefit from an official version of sorts of this type of information. |
Because the Go team cannot know all uses of Go and what project layout each type of project would benefit the most. In general, just tossing a few .go files in the same dir will take you very far. |
|
I think I missed something in my original comment. This was at a time when I was moving from small one off projects, to something significantly larger at work while I was still learning an uncertain about what I was doing. I don't know the best solution, but it seems like there could be at least a bit more in that regard. Honestly even if it was a wiki page with some "hey this could be useful" comments regarding laying things out when the time comes. |
|
This blog post has always been a great place to start, and it's worth noting that @eliben, whose article I posted above is in the Golang organization. There's also this post by @rakyll (former Go Team member) and this one by @peterbourgon. These articles may not be quite as specific or official as some people might want, but like our earlier poster mentioned, everyone's needs are different, and the official guidelines have had a correspondingly broader scope. Should is a tough concept in software engineering, and once you say things should be done a particular way, it's tougher to evolve and to develop new best practices. The more specific and proscriptive you are, the tougher it becomes, from my experience. Far better to have clear, philosophical guidelines describing the guiding principles of the language and how those can shape the reusable components you write. And I do think we have that. Put another way: "it depends", and giving it a proper treatment involves, ideally, multiple case studies on "well structured" packages that take design, intent and API footprint into consideration, along with how those decisions were arrived at, why, and how they may have evolved through the life of the project. Perhaps theres some room for this in the Go Blog, but even then the answer is still "it depends", and what works for one package might not work well for another, even if the guiding principles are the same. And, of course, when I google "structure golang programs", this repo is still on top, which is the crux of #117 |
|
22k stars shows there is a community need for something like this. I understand the "it depends" camp for complex projects, but there are guidelines that most people can agree with. For example, the vast majority of simple go projects, when they are starting out, have a go.mod at the root path with a package that probably matches the github repository. There's probably a LICENSE file and README file. They probably should check in their go.sum file. There should probably be a package_test.go file. There are other best practices where their existence is important, even if the details are not. For example, almost all have CI, but we don't have to make a decision on which CI is best. With 22k stars, the community is signaling a strong need for guidance on how to structure go projects. I believe it would be high leverage for an official voice, more recent than 2012, with access to golang.org, to guide people here. |
|
I am not sure we can assume the user's intent when they star a project. I know for many it signals an interest to understand or explore a project later. It does not mean that they have a need for it. I star some projects I never use, nor ever have a need for. |
|
@rsc Does the Go team have an official project layout pattern? |
|
Go doesn't have an official project layout. I always use the layout like here: https://github.com/golang/go/tree/master/src and itś simple: a folder with that package and all related. Go is simple, I don't know why developers want to use patterns of others languages here. |
|
@xhit considering we have |
|
I think an excellent start to anything even remotely like this could just be to point out the resources you've all been dumping as alternatives. There's all this great info spread all over. Should be enough to at least have a wiki page that you can point people to, when they've been mislead. It's also a good option incase this org sticks around longer. |
|
I think discussions about a standardised project layout miss the point. Go encourages you to derive package names from the last path component. When importing multiple packages, you want the names of the packages you import to be unique to avoid naming collisions. A standard layout would mean that it's very likely that many of the packages have the same, standard names and hence collide. This is to be avoided. So in order to make for a good programmer experience, the layout must not be standard but rather custom and different for each project. I believe that people overthink this way too much. Just let your projects grow organically. Except for a few hard coded directory and file names (like |
|
I think that this stems from new people coming to the language looking for guidance on best practices for project layout out. This is especially true if you come from a very well structured world like Django, Flask or Rails and so on where project structure is defined for you, this is where you put your handlers and your models go here etc etc. Coming to go where that safety net does not exist can be a little daunting for new comers, for myself coming to go from the Django world I struggled with how to layout projects, "I was always asking myself am I doing it right?" and while the correct answer is that there is no right way, only the way makes sense for what you are building, the I've long stopped laying out my projects specifically like this because I've grown in experience and naturally figure out project layout on the fly and it's naturally evolving as the codebase grows and evolves, things will move around a bit and thats ok. Perhaps the issue is that this project aims to be THE way to layout a go project when really it's more like a here is a place to start to inspire you. It's certainly not the standard way though. |
|
Not long ago, I also encountered such a problem. I used to be engaged in the development of other languages and have certain development experience. When I want to use golang to develop a project, and for this to establish a good code directory structure, I am confused. |
|
As a young gopher, I prefer simplicity,i like the layout list : |
|
Yeahh, let's delete this missguided repo |
|
I have some sympathy with @rsc about this (OK, a lot of sympathy). I don't think the layout shown in this repo represents either the best way to structure Go projects, or even the most common way (those are quite different things, as you'll appreciate). That said, though, I guess the author of this repo can publish whatever he wants, even describing it as a "standard", and no one can say boo about it—not even Russ. That's the joy and the hurt of open source. No one is obliged to pay any attention to the maintainer's ideas about Go project structure, and the flipside of that is that he's not obliged to pay any attention to us. If someone thinks they can do better (and the Go team would seem to be an obvious candidate for this), let them go ahead and do so. I read about a dozen blog posts a day about Go which are (in my opinion) at best misguided, and at worst positively harmful. It would be a full-time job for me to try to get the authors to change their minds, and posts, and it's none of my business anyway. Instead, I publish my own opinions, and let Gophers decide whose ideas they like best. That seems to me a sensible way of going about things. |
|
@bitfield The org should be renamed. It's that simple. It's misleading, it harms devs new to Go. It's ok that Go doesn't have a standard project structure. Any given project's structure is a function of its size, complexity and type. Go is versatile, so it makes sense that there would be a bunch of different structure choices depending on what exactly your project is. It also fits that new devs would be looking to better organise their code once the single main.go starts to get a bit out of hand, especially when coming from a file per class language. They search Google, they find this repo. Because of its name not its readme. It's very easy to miss that comment in the readme. It's by no means a sufficient disclaimer. That comment is a massive copout from the owners because they know they'll get no further traction if they renamed the org. Maybe they should instead focus on demonstrating how different potential project layouts could fit different use cases, and make it actually useful to new Gophers with some signposting of that nature. "Start here with a basic layout", "here's one with a bit more organisation", etc. |
|
@m2q The standard opiniated directory structure for Go is no directory structure. Name every package according to its function. Chose unique names, not names everybody else uses. No fun programming if you import 10 packages named Perhaps the only thing resembling a convention is having |
|
It's fine to put out a recommended layout, even one that may be imperfect. @bitfield is right to point out that there are plenty of blog posts with questionable suggestions out there. I'm not sure this can be put into that bucket, as blogs published under the names of individuals or organizations will be generally understood as reflecting only the author's perspective. Who would have the audacity to call their organization "golang-standards" if they have neither the authority to set standards nor consensus from the community that what they are promoting is a best practice? It's not uncommon for new gophers to make the fairly sensible assumption that the answer to this question is "nobody", and rather than pursuing further perspectives, they take this repo to be the final answer that its name implies it to be. (No, a disclaimer in the readme does not adequately mitigate that. How often do you read a readme from top to bottom?) It's a fine project, but an irresponsible name, and it would be tremendously helpful to the community if the name were changed to convey the humility which I'm sure the author intended to bring to this project. |
|
Lol, i have a great idea: If this layout is not official (yet, maybe), instead of renaming, why not to work on it? 🤔 I mean, go still doesn't have best practices of directory layout (unlike rust, dart, etc. note that they have recommendations, not restrictions), why not create a recommended only standard of layout (only as recommendation, like effective go, gofmt, etc.) that suits most of gophers tasks including language core developers? People say here right thing (like @flowchartsman): go is so simple that you can write the code as you feel it and it looks good. Honestly, this repository is not needed at all in current status 😂 but despite this, some kind of agreement is still needed where long-time gophers where to find specific logic with unknown project to them (for example, Kubernetes and Prometheus are rather complex sources, but at the same time coode looks slightly similar, I do not want to be tied to this particular projects or this repository at all, so with such recommendations it is easier to understand where someone else's code stores and how it relates to each other.) The question is not so much in standardizing the layout, but in explaining to newbies how long-time gophers are storing their code by functionality
|
As someone who has tried to learn to Go (not my first language!), I can attest to the immense complexity often presented as a supposed "standard" of the language. This issue is particularly troubling for new individuals attempting to enter the world of Gophers, as it can significantly deter their progress and success. |
|
@paulwizviz You are so insanely wrong and off base that it's not even worth replying to your points. Please see the entire conversation above... |
So why are you tagging me? Since I am, in your words, "so insanely wrong and off base"? |
|
Yes, the definition of standard includes "official rules". It is reasonable to believe that, used in this context, this word would be construed as having this meaning. It is unreasonable to assert that, for words having multiple meanings, that it is unambiguous as to which meaning was intended, as the only possible way to truly measure that is to scan the brainwaves of readers.
|
Since you brought up the definition of standards for units of measure. Here are some facts for you to ponder. Norwegian and Swedes have a measure of distance called miles (https://en.wikipedia.org/wiki/Scandinavian_mile). To them, 1 mile is 10 km. Do you see the brits or US standard agencies complaining to the Norwegian and Swedes that they should not use the word miles as it is "not standard"? Or a gallon in the US is not the same as GB? In GB that is the Imperial standard and in the US is based on their own standard. I don't see the Brits and the US complaining that either one not complying with the "standard". And it might cause confusion. "Official" standard as it were does not mean one. There is ISO standard, US standard, British standard, etc. So in your definitions, you see the word "industry standards" -- plural -- not "industry standard" -- singular. That is the world we live in. Time to get used to it. |
So what is your point? The fact that it does not represent any or the fact that it is not worthy of attention? |
Maybe that is your opinion. If people can't judge the content of something and get so worked up over the use of a word then clearly something is wrong. Just to be clear, I neither endorse the use of the word "standard" nor do I care if the word "standard" is used. Just as long as the caveat is clearly mentioned. I would have an issue if this repository deliberately deceive me by claiming to speak on behalf of the Go core team -- i.e. the people I can identify as creators of the language or delegated representatives. NOTE: I am avoiding the term "official" as that term has other even more toxic meanings. |
Since when does the name implies the Go core team endorse them? Just because of the word "standard"? Would the name "go-standards" be ok? I don't see Go games associations claiming that the core team should not use the name Go as it would confuse people who want to learn to play Go. |
|
Isn't the language just called "Go," so I'm not seeing an automatic
endorsement from Google in the name? The only problem is the one people
are trying to create here. People get things wrong, and then they learn
from it.
We can get all philosophical we want with it, it doesn't change the fact
that Google has an army of people they pay to look after their interest. I
think we all know that Google has way more than enough bank behind it to
quash this issue in a heartbeat, but I'm not really sure this is the hill
I'd choose to die on.
Who are you going to go after next just because you don't like the name, or
you find it confusing? I don't want this drama, and personally it kind of
makes the community look ugly and petty.
I've since moved on from this project, so why can't some of you? Nobody is
perfect, and really we are trying to rally the troops here, just because
some people think this project stinks?
That's the type of "elitism" that some languages tend to suffer from ... I
really would love to see Go blossom socially, but at the same time I can
see why Google is also throwing money into other languages such as
Flutter/Dart and Carbon. Assuming Go is the best language, history tells
us the best doesn't always win out.
Can we finally put a pin in this? Where is this a stopping issue, and
what's really being injured here other than egos?
…On Wed, May 17, 2023 at 4:32 AM Paul Sitoh ***@***.***> wrote:
@paulwizviz <https://github.com/paulwizviz> The name "golang-standards"
implies that the Go core team endorses them, which they clearly do not.
Nitpicking about dictionary definitions or Norwegian units of measure
doesn't change that.
Since when does the name implies the Go core team endorse them?
Just because of the word "standard"?
Would the name "go-standards" be ok?
I don't see Go games associations claiming that the core team should not
use the name Go as it would confuse people who want to learn to play Go.
—
Reply to this email directly, view it on GitHub
<#117 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAUEEH2KJXMSEU3Y6D22RL3XGSZN5ANCNFSM42VNPM4A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The injury is that people who are new to the Go language think that this repository describes good Go programming practices. This leads to confusion and disappointment. It seems to me that we should try to avoid confusing and disappointing people who are just starting out with the language.
For this kind of argument you have to multiply the large amount of power that Google has by the small amount of interest that Google has for this issue. |
|
On May 17, 2023, at 3:41 AM, Paul Sitoh ***@***.***> wrote:
Norwegian and Swedes have a measure of distance called miles. To them, 1 mile is 10 km. Do you see the brits or US standard agencies complaining to the Norwegian and Swedes that they should not use the word miles as it is "not standard"?
Or a gallon in the US is not the same as GB? In GB that is the Imperial standard and in the US is based on their own standard. I don't see the Brits and the US complaining that either one complaining about each other not complying with the "standard".
Those analogies are flawed.
The Scandinavians do not call it a "standard mile", then just call is a "mile."
The British do not call it an "international standard gallon" they clarify that it is the "Imperial (British) standard gallon."
On May 17, 2023, at 3:57 AM, Paul Sitoh ***@***.***> wrote:
Just to be clear, to me, I neither endorse the use of the word "standard" nor do I care if the word "standard" is used. Just as long as the caveat is clearly mentioned. I would have an issue if this repository deliberately deceive by claiming to speak on behalf of the Go core team -- i.e. the people I can identify as creators of the language or delegated representatives. NOTE: I am avoiding the term "official" as that term has other even more toxic meanings.
This repo's "About" styles itself as the "Standard Go Project Layout" at a Github org named "golang-standards" thus strongly asserting itself as *the* standard, especially to the uninitiated.
Had the repo owner positioned it as "Example Go Project Layout" or just "Go Project Layout" a Github org named "golang-examples" I think very few people would be taking the time to complain, and especially not the GoLang project leads.
Point of note: No caveat is clearly mentioned in this repo's "About" section or on the golang-standards" Github org page. If the "About" were changed to be "A Standard Go Project Layout — not official endorsed by the GoLang Authors" AND on the "golang-standards" org page included a description like "A set of standard artifacts for GoLang projects — not official endorsed by the GoLang Authors" then that would likely be an appropriate caveat.
But since no such caveat exists that will likely be seen by anyone visiting these pages this org+repo seems to fail even your own criteria for forthrightness.
P.S. Why is this topic a hill you want to die on? Just trying to understand your intensity on this thread.
|
|
On May 17, 2023, at 11:54 AM, Topcheese ***@***.***> wrote:
Isn't the language just called "Go," so I'm not seeing an automatic
endorsement from Google in the name?
Point of note: The official website for the Go programming languages is hosted at "golang.org."
The only problem is the one people are trying to create here. People get things
wrong, and then they learn from it.
There is a problem you are not acknowledging and that is that many people new to Go will find this and believe it is the officially correct way to layout a project. Then they will create Go projects that will from day one start with significant technical debt because of the mismatch between this pattern's structure and more optimal ways of structuring Go code.
This is much the same as copyright law; copyright infringement is not limited to exact usage of copyright but expands to include any usages that for a reasonable person would cause confusion.
Analogously, the fact that a few specific individuals such as yourself do not see a problem with this repo is not the concern of the many who argue against this repo. Their concern — if I may make such an assumption on their behalf — is that those who do not know better will be confused into thinking that this repo represents an official Go standard. And given the number of people in this thread echoing a concern about this repo I think it has been proven that there are many reasonable people are concerned that it would cause confusion.
Where is this a stopping issue, and what's really being injured here other than egos?
I have worked on three (3) different large projects that were based on this layout and each of them have been a nightmare of unnecessary complexity that has cost their owners hundreds of thousands of dollars in unnecessary maintenance cost.
That unnecessary expense and expanded score and missed deadlines are a lot more than just egos harmed.
…-Mike
|
The analogy is most apt. The terms in contention are related to the term used to refer to distance -- the same term referring to different things. Why die on this topic? I find this picking on labels and not content very disturbing. And it demonstrates pettiness in the Go/Golang communities which is scary to me. Might I say it has taken on a form of a culture war that is mimicking the real world you see in Florida in the USA -- e.g. telling people they can't self-identify their own gender. Where is this nitpicking going to stop? If this continues with an inability to disambiguate between labels and content, anytime anyone sharing thoughts is going to be picked on by all these nitpickers. Also, the fact of the matter, is we don't live in a clean-cut world where everything is clear. And part of software engineering education as opposed to just coding by "official" standards is about learning to accept differences. And if the Go core team wants to justify that there is an "optimal" way to layout a project they would have done so now. The fact that they have not suggests that there is no "optimal" and it is up to the community to find their own way or possibly by consensus to establish a norm -- another word for "standard". On your assertion that the repo was named differently, the problem will go away. I doubt it. One of the points raised by @rsc is that this repo had gained traction and that it was, to paraphrase, it was the wrong thing to do. He noted there were projects asking for the layout to compile with this repo. Now if the repo is named differently (let's call it If the argument was the labelling misled people to enforce this layout as a "golang-standard", then it is for @rsc and others to prove the case. I am guessing we still live in a world where you are innocent until proven guilty @mikeschinkel? Now I know what you are going to argue no this layout is wrong. This then leads to the question so now is the objection related to the label of the repo or the content? I am guessing you are going to argue that based on @mikeschinkel experience it makes your project hard to manage. That's your opinion. In my case, I came to learn about this layout not simply by googling and hitting on this and then blindly following it. On the contrary, I learned from attending meetups and listening to people presenting their pains with layout of the Go project and some were alerted to this I started experimenting and found it solved my problem. I even collaborated with other projects to find that similar pattern of layout. So I have continued to be inspired by this layout, where appropriate, for my projects especially complex ones. So you see just because you don't find it useful does not mean it is wrong. Others might find it too. When I mentioned this layout I was often told it is "wrong" of me to use it. So clearly, demonstrates the fact name changes won't alter. Look at the Go Gin framework, it is not idiomatic Go -- i.e. not following a pattern practice in the core library or standard lib -- and not something I would use unless I have to because it is already baked in. But just because it is not to my liking does not mean others (possibly a sizeable number to even justify it being a defacto standard, but who knows) prefer to use it and they are wrong to use it. At the end of the day, it is all about choice, not some ideology. As for the caveat in this repo here is what is written in the README.
If this is not clear enough I don't know what is. |
|
It is certainly not "basic" (in what world is a "basic layout" not suitable for a "simple project"?), nor was it "common" except that, by insisting that it is in fact a standard layout, and people following along, it made itself so. The fact that the Scandinavian mil is not an English mile was already addressed. It is in truth a mere false friend. Obviously they do derive from the same root. The mil doesn't cause conflict because that's not how it is used outside Norway and Sweden. There is a reason we have the international mile. Currently, that page even mentions that the proper way to refer to other so-called "miles" (mil, miglio, li, etc.) is with a qualifier. Worse, the very claim you are making about "diverging standards exist, deal with it" is refuted by the very sources you cite. The "Scandinavian mil" is a post-metrication product created from the Norwegian mil and Swedish mil, which were 11295 meters and 10688 meters, respectively. They were truncated into the same 10 kilometer measure. The Swedish mile itself was varying measures in Sweden before being standardized in 1699! As for the international mile, it exists because an international treaty was concluded to unify the UK and USA's meaning of the mile. The history of the world is not that people "deal with" divergent standards, but rather that they, er, standardize them, and often pass that into a matter of law, thus inflicting formal penalties for non-conformance. Thus, claiming you are a standard tends to have a weight to it because we live in a culture where many standards have been in fact enforced, sometimes violently, though usually more implicitly (e.g. fees, fines). Identifying a "standard" implies, at least, social consequences for being in non-conformance, such as confusion of others and them responding by yelling at you and denouncing your name for not using it. Avoiding a (known) source of social approbation seems to be an instinct in most humans, thus a lot of people develop a reflex to obey anything that is presented as a "standard". That reflex tends to preempt thinking, or indeed, reading carefully-worded caveats presented in any README. |
|
It's fine that the authors mention that it's not a standard Go project layout, but why not change the GitHub org name then? |
|
@feketegy There are many movies that are based, in some cases very loosely, on historical figures (i.e. Gandhi, Patton, Oppenheimer, etc) and events that film maker has to disclaim. Why then do they not change the name of the movie? Won't it confused people into thinking it is a about history? |
|
@paulwizviz I don't think you'll win anyone with that particular argument... |
|
lol 😂 what kind of argument is that... |
Well it's really not about wining. It's about showing the narrow-minded bunch of people who complains about labels and not about a content. Whilst they demonstrate selective application of their argument. As so many people are revealing themselves to be. Anyway it's up to them, they can think and say what they like. Just as much as the person who took the GitHub name as he has not violated any rules. |
|
@paulwizviz @svengreb Despite nobody agreeing with you, you continue to post random confusing arguments. The issue is clear: people see "golang-standards" and assume this is the standard layout. |
@paralin if that is the case why tag me. If you want to be narrow minded so be it. Typical of narrow-minded people who think only their view is the right one. What is even more ironic is for someone who don't believe in this project, keep posting here and claiming others to "post random confusing arguments". And still can't see the irony of own arguments. If you don't believe in it why subscribe here. |
|
Can you guys stop arguing and take your cat fight to dms? Seriously. Nothing is going to happen to this repo as a result of any of these discussions. Its a dead topic. |
|
This repo does contain a lot of questionable advice. So I would advise anyone looking for a starting point for project layout to look instead at the examples published by the Go team themselves. |
and others
The README makes clear that this is not official, but even the claim "it is a set of common historical and emerging project layout patterns in the Go ecosystem" is not accurate.
For example, the vast majority of packages in the Go ecosystem do not put the importable packages in a
pkgsubdirectory. More generally what is described here is just very complex, and Go repos tend to be much simpler.It is unfortunate that this is being put forth as "golang-standards" when it really is not. I'm commenting here because I am starting to see people say things like "you are not using the standard Go project layout" and linking to this repo.
The text was updated successfully, but these errors were encountered: