3 ms·

gofmt being the official tool avoids bikeshedding over formatting rules. Diverging from the default seems like a step backwards, doesn't it?

usrme 4y ago
In the roadmap section[1] the author says it's more of an experiment with a possibility that some of the rules might end up in the original 'gofmt' tool. While I agree that Go having a de facto formatter built in is wonderful, there are some absolutely fantastic additions in 'gofumpt' that I do hope wind up in 'gofmt' --- [1]: https://github.com/mvdan/gofumpt#roadmap https://github.com/mvdan/gofumpt#roadmap
- rickette 4y ago
  Ok that sounds great
burnished 4y ago
A little yeah, but I think it still raises the base level of effort to nitpick trivial stuff enough to be effective.
fivre 4y ago
very much so imo. the standard formatter is one of the things go very much does right my protests against requiring this, as additional friction for our OSS contributors especially, unfortunately fell on deaf ears. unfortunately i just don't have the energy to beat my more pedantic coworkers over the head with the notion that if these additional formatting rules are that important to them they need to do the legwork to pull them into mainline gofmt nah, that's actual work. an additional hurdle in the dev environment for some random formatting things that nobody will ever notice though, you can enforce that in a few lines of CI scaffolding, so into the checks it goes
- deleted 4y ago
  [deleted]
- mvdan 4y ago
  It's not quite as simple as that :) I think upstreaming half of gofumpt's additions to gofmt would be reasonable, but the person who wrote and maintains gofmt is Robert Griesemer, who continues to be quite busy with generics. They are still actively fixing typechecking bugs and performance issues, as far as I can see. I think it's hard for anyone to justify pausing or distracting the generics work in favor of upstreaming parts of gofumpt. At the end of the day, gofumpt works today - it's just a bit awkward to have it as a third party tool. That said, it is on my radar to talk to him and make a plan for upstreaming. Edit: to clarify what I mean with the above: I of course could do the legwork to port my formatting changes to go/printer, the guts of gofmt. The reason I mention Robert is that he'd be the one to consider and approve each formatting change, and review the code changes and tests. That work is trickier than it sounds, because you have to think about the possible effect any formatting change would have on all kinds of existing Go code out there.
  - typical182 4y ago
    For open source projects in general, and the Go project in particular, I think it is easy to underestimate how much maintainer time is consumed discussing & considering whether a change should be made.
shp0ngle 4y ago
gofumpt is just stricter. It has gofmt as a baseline and adds other rules.

usrme 4y ago

In the roadmap section[1] the author says it's more of an experiment with a possibility that some of the rules might end up in the original 'gofmt' tool. While I agree that Go having a de facto formatter built in is wonderful, there are some absolutely fantastic additions in 'gofumpt' that I do hope wind up in 'gofmt' --- [1]: https://github.com/mvdan/gofumpt#roadmap https://github.com/mvdan/gofumpt#roadmap

rickette 4y ago
Ok that sounds great

burnished 4y ago

A little yeah, but I think it still raises the base level of effort to nitpick trivial stuff enough to be effective.

fivre 4y ago

very much so imo. the standard formatter is one of the things go very much does right my protests against requiring this, as additional friction for our OSS contributors especially, unfortunately fell on deaf ears. unfortunately i just don't have the energy to beat my more pedantic coworkers over the head with the notion that if these additional formatting rules are that important to them they need to do the legwork to pull them into mainline gofmt nah, that's actual work. an additional hurdle in the dev environment for some random formatting things that nobody will ever notice though, you can enforce that in a few lines of CI scaffolding, so into the checks it goes

deleted 4y ago
[deleted]
mvdan 4y ago
It's not quite as simple as that :) I think upstreaming half of gofumpt's additions to gofmt would be reasonable, but the person who wrote and maintains gofmt is Robert Griesemer, who continues to be quite busy with generics. They are still actively fixing typechecking bugs and performance issues, as far as I can see. I think it's hard for anyone to justify pausing or distracting the generics work in favor of upstreaming parts of gofumpt. At the end of the day, gofumpt works today - it's just a bit awkward to have it as a third party tool. That said, it is on my radar to talk to him and make a plan for upstreaming. Edit: to clarify what I mean with the above: I of course could do the legwork to port my formatting changes to go/printer, the guts of gofmt. The reason I mention Robert is that he'd be the one to consider and approve each formatting change, and review the code changes and tests. That work is trickier than it sounds, because you have to think about the possible effect any formatting change would have on all kinds of existing Go code out there.
- typical182 4y ago
  For open source projects in general, and the Go project in particular, I think it is easy to underestimate how much maintainer time is consumed discussing & considering whether a change should be made.

shp0ngle 4y ago

gofumpt is just stricter. It has gofmt as a baseline and adds other rules.