30 ms·

Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature c

by sliken 4y ago

Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature comes out the time to implementation may vary. Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? Generally in the go community, contributions, patches, code, etc that's not formatted with gofmt is considered wrong/broken.

gkop 4y ago
Thanks! More curiosity: How do humans that disagree with the One Format deal with it? Do they self-select away from Go? > Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? How does the format evolve over time as the community discovers improvements (if it does), and what are the implications for code on github?
- theshrike79 4y ago
  "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." - Rob Pike This pretty much sums it up. Gofmt isn't perfect, but everyone uses it and deals with it. It's included with the language so there's no point in trying to create a "competitor".
- sliken 4y ago
  Generally I think most agree that gofmt makes pretty good decisions and it's better to have one format than competing formats that make it ugly when someone joins the team, or you are importing a library. The more you read code the nicer it is to have it all in the same format. Like much of go, there's the "go" way to do it, and the language simplicity reduces the chance of multiple programmers taking multiple approaches that are all different enough to require wrappers to interoperate. Sure your pet feature from some other language may be missing. The language (and gofmt) have evolved. In particular since the parser is externally usable (by gofmt, IDEs, and other tools) you can actually use that tool to rename variables, functions, etc without having to worry about getting a REGEXP right. So when there's the occasional incompatible change gofmt can parse code into a tree, make a transformation, and then back info code ... including comments. It's relatively common (in my experience anyways) to have commit hooks in git run gofmt on go code. Generally go's been very compatible, none of the issues like Python2 vs Python3. I'm sure some avoid go for these reasons, but I lump them in with folks that reject python because of whitespace/indenting.
- PeterisP 4y ago
  If you disagree with the One Format, you can configure your IDE to show (or transform) the code in a different style while you're working with it, and have the One Format be the format for storage of the source.
- returningfory2 4y ago
  The point of view in Go is that the specific format is irrelevant. The design choices made by the format don't matter. What you think is "nice" code and what someone else thinks is "nice" code doesn't matter. The benefit of formatting has nothing to do with making the code conform to anyone's definition of "nice". It's just about having a format that's passable and that is then applied uniformly.
mountainriver 4y ago
It’s also an example of how Go thinks about all problems. Do things one way that is well made and roughly satisfies most use cases
- kaba0 4y ago
  (Other than Generics, which was known to be required decades before its existence.. sorry)
  - smokey_circles 4y ago
    required is a strong, but personal opinion. go's generics are just type switches for the lazy (over simplified)

by sliken 4y ago

gkop 4y ago

Thanks! More curiosity: How do humans that disagree with the One Format deal with it? Do they self-select away from Go? > Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? How does the format evolve over time as the community discovers improvements (if it does), and what are the implications for code on github?

theshrike79 4y ago
"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." - Rob Pike This pretty much sums it up. Gofmt isn't perfect, but everyone uses it and deals with it. It's included with the language so there's no point in trying to create a "competitor".
sliken 4y ago
Generally I think most agree that gofmt makes pretty good decisions and it's better to have one format than competing formats that make it ugly when someone joins the team, or you are importing a library. The more you read code the nicer it is to have it all in the same format. Like much of go, there's the "go" way to do it, and the language simplicity reduces the chance of multiple programmers taking multiple approaches that are all different enough to require wrappers to interoperate. Sure your pet feature from some other language may be missing. The language (and gofmt) have evolved. In particular since the parser is externally usable (by gofmt, IDEs, and other tools) you can actually use that tool to rename variables, functions, etc without having to worry about getting a REGEXP right. So when there's the occasional incompatible change gofmt can parse code into a tree, make a transformation, and then back info code ... including comments. It's relatively common (in my experience anyways) to have commit hooks in git run gofmt on go code. Generally go's been very compatible, none of the issues like Python2 vs Python3. I'm sure some avoid go for these reasons, but I lump them in with folks that reject python because of whitespace/indenting.
PeterisP 4y ago
If you disagree with the One Format, you can configure your IDE to show (or transform) the code in a different style while you're working with it, and have the One Format be the format for storage of the source.
returningfory2 4y ago
The point of view in Go is that the specific format is irrelevant. The design choices made by the format don't matter. What you think is "nice" code and what someone else thinks is "nice" code doesn't matter. The benefit of formatting has nothing to do with making the code conform to anyone's definition of "nice". It's just about having a format that's passable and that is then applied uniformly.

mountainriver 4y ago

It’s also an example of how Go thinks about all problems. Do things one way that is well made and roughly satisfies most use cases

kaba0 4y ago
(Other than Generics, which was known to be required decades before its existence.. sorry)
- smokey_circles 4y ago
  required is a strong, but personal opinion. go's generics are just type switches for the lazy (over simplified)