I've seen go code fail to compile because a closing } was on the next line and there wasn't a trailing comma. I'd fully expect a formatter to handle that kind of minutiae for me.
I've seen go code fail to compile because a closing } was on the next line and there wasn't a trailing comma.
That actually is a syntax error, as go enforces (that is they are not optional) trailing commas. gofmt only formats syntactically correct code.
I get that a formatter should reject syntactically incorrect code, but I question why it's syntax error in the first place. Coming from using black with python, I generally leave the trailing comma there but for the compiler to care seems weird when there's a standard formatter available.
The compiler cares because they want to enforce this standard (and it may make the parser slightly simpler). That there is a mix, or at least a non-obvious break between what the compiler enforces and what the formatter will accept and produce is an inconsistency in go, I suppose, but not necessarily worse than arbitrary decisions made in other languages.
Oh absolutely, do use gofmt, always.
The above example was just to make a point, and perhaps give insights into how the compiler works.
IMHO, Go's 'enforcement' of common formatting is powerful; it has an incredible compound effect which gains momentum as you get acquainted with the language.
Generally, extra tabs and spaces do not change semantics; nor do new lines (when inlining statements you just can't imply the semicolon).
Go files run just fine without any indentation whatsoever. People often assume enforced formatting by the `gofmt` tool is mandatory for the compiler, but most of it is addressed at human beings for readability.
Here's the 'official' blog post about gofmt: https://blog.golang.org/go-fmt-your-code
Edit: downvotes don't change reality ; )
Try it yourself: https://play.golang.org/p/_bXvXryM5Ih — how incredibly ugly, and yet it runs just fine. Please hit format to clean your eyes.