Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

this is not a standard Go project layout #117

Closed
rsc opened this issue Apr 9, 2021 · 255 comments
Closed

this is not a standard Go project layout #117

rsc opened this issue Apr 9, 2021 · 255 comments

Comments

@rsc
Copy link

rsc commented Apr 9, 2021

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 pkg subdirectory. 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.

@iarosb
Copy link

iarosb commented Apr 13, 2021

@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.

@henvic

This comment was marked as abuse.

@iarosb
Copy link

iarosb commented Apr 15, 2021

@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.

@rakyll
Copy link

rakyll commented Apr 17, 2021

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.

leoschet pushed a commit to leoschet/gaivota that referenced this issue Apr 18, 2021
@theckman
Copy link

theckman commented Apr 23, 2021

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

@flowchartsman
Copy link

flowchartsman commented Apr 24, 2021

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.

@MrTravisB
Copy link

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.

@flowchartsman
Copy link

flowchartsman commented Apr 27, 2021

I think the primary issue is that the org is titled golang-standards which, combined with its age, lends it a certain credibility (not to mention SEO) that is unwarranted and has long been a source of confusion for new developers.

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.

@SteelPhase
Copy link

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.

@ivarec
Copy link

ivarec commented Apr 27, 2021

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.

@SteelPhase
Copy link

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.

@flowchartsman
Copy link

flowchartsman commented Apr 28, 2021

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

@cep21
Copy link

cep21 commented Apr 28, 2021

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.

@theckman
Copy link

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.

@masakatsu-corp
Copy link

@rsc Does the Go team have an official project layout pattern?

@xhit
Copy link

xhit commented Apr 28, 2021

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.

@theckman
Copy link

@xhit considering we have go fmt to consistently style source code, I could see some then wanting or even expecting to find a style to use consistently to structure their project. I think there are some patterns we've discovered over the years that can help projects be more easily maintained, but I think that's much different that some sort of one-size-fits-all "standard" layout.

@SteelPhase
Copy link

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.

@clausecker
Copy link

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 vendor, testdata, and go.mod) you are free to chose whatever directory names you like. You should
make full use of this freedom and put your stuff into whatever directory name seems most appropriate for the problem at hand. And if this choice turns out to be a poor one, you can always refactor later.

@krak3n
Copy link

krak3n commented Apr 28, 2021

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 golang-standards/project-layout gives a guide to how you might start and grow from there.

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.

@lyonnee
Copy link

lyonnee commented Apr 28, 2021

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.
Later, after looking at this project and understanding the compilation rules of golang, I developed a "standard layout" of my own project.

@auula
Copy link

auula commented Apr 28, 2021

As a young gopher, I prefer simplicity,i like the layout list :

@batara666
Copy link

batara666 commented Apr 28, 2021

Yeahh, let's delete this missguided repo

@bitfield
Copy link

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.

@batara666
Copy link

@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.

@clausecker
Copy link

clausecker commented Apr 28, 2021

@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 util. And do not add boilerplate path components like src, util, or pkg. Nobody needs that.

Perhaps the only thing resembling a convention is having cmd for main packages as the second-to-last path component. And of course the few hard-coded directory and file names.

@colin-p-hill
Copy link

colin-p-hill commented Apr 28, 2021

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.

@quenbyako
Copy link

quenbyako commented Apr 28, 2021

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

guys how dislike it: instead of being toxic, explain your opinion. I look at your thumbs down and not fully understanding whats wrong with my comment, why not to explain your position?

@ologbonowiwi
Copy link

Let me put it this way, Just because the word "standard" is used, does it make this content official?

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.

@paralin
Copy link

paralin commented Apr 30, 2023

@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...

@paulwizviz
Copy link

paulwizviz commented Apr 30, 2023

@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"?

@workingjubilee
Copy link

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.

unit of measurement, countable: a unit of measurement that is officially used; an official rule used when producing something. "a reduction in the weight standard of silver coins." "industry standards." see "gold standard".

@paulwizviz
Copy link

paulwizviz commented May 17, 2023

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.

unit of measurement, countable: a unit of measurement that is officially used; an official rule used when producing something. "a reduction in the weight standard of silver coins." "industry standards." see "gold standard".

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.

@paulwizviz
Copy link

"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.

@paulwizviz There are many industry standards. This repository represents none of them.

So what is your point?

The fact that it does not represent any or the fact that it is not worthy of attention?

@paulwizviz
Copy link

paulwizviz commented May 17, 2023

"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.

@paulwizviz There are many industry standards. This repository represents none of them.

So what is your point?
The fact that it does not represent any or the fact that it is not worthy of attention?

Mostly the fact that the organization is not worthy of the name "golang-standards"...

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.

@paulwizviz
Copy link

@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.

@topcheese
Copy link

topcheese commented May 17, 2023 via email

@ianlancetaylor
Copy link

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.

I think we all know that Google has way more than enough bank behind it to quash this issue in a heartbeat,

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.

@mikeschinkel
Copy link

mikeschinkel commented May 17, 2023 via email

@mikeschinkel
Copy link

mikeschinkel commented May 17, 2023 via email

@paulwizviz
Copy link

paulwizviz commented May 18, 2023

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.

@mikeschinkel

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 go-project-layout, and it started to attach more and more people ask for the project to comply with this layout to onboard the project. Let's assume that it gains traction and becomes a defacto "standard", will @rsc and/or his colleagues object to 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.

This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.

If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a single main.gofile andgo.mod is more than enough).

If this is not clear enough I don't know what is.

@workingjubilee
Copy link

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.

@feketegy
Copy link

feketegy commented Aug 3, 2023

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?

@paulwizviz
Copy link

@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?

@paralin
Copy link

paralin commented Aug 5, 2023

@paulwizviz I don't think you'll win anyone with that particular argument...

@feketegy
Copy link

feketegy commented Aug 5, 2023

lol 😂 what kind of argument is that...

@paulwizviz
Copy link

paulwizviz commented Aug 5, 2023

@paulwizviz I don't think you'll win anyone with that particular argument...

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.

@paralin
Copy link

paralin commented Aug 5, 2023

@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.

@paulwizviz
Copy link

paulwizviz commented Aug 5, 2023

@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.

@cameracker
Copy link

cameracker commented Aug 5, 2023

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.

@amnonbc
Copy link

amnonbc commented Aug 19, 2023

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.

https://go.googlesource.com/example/+/refs/heads/master

@golang-standards golang-standards locked as resolved and limited conversation to collaborators Aug 19, 2023
@kcq kcq closed this as completed Aug 19, 2023
@golang-standards golang-standards deleted a comment from paralin Aug 24, 2023
@golang-standards golang-standards deleted a comment from dominikbraun Aug 24, 2023
@golang-standards golang-standards deleted a comment from dominikbraun Aug 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.