I can agree with gofmt being great, but I can't agree that a simple newline before a brace should be treated as a syntax error. You're forced to use Google's coding style, whether you like it or not. Preferred coding style is subjective, and Go ignores the fact that not everyone works for Google.

I don't know why they are modding you down, but is true, code formatting is subjetive and Google enginers do not hold universal truth.

It's not subjective when the language dictates that's how it's to be done. Coding style changes based on the language you're writing in, Go just happens to have a very strict style.

I think this is the thing I want most languages to adopt. As someone responsible for ensuring a team's work can be supported by new developers, gofmt is a life saver.

Indeed, forget goroutines and channels. The most innovative thing Go brings to programming is gofmt. Between that and the simplicity of the language, it makes it so easy to dive into large foreign code bases and actually understand what you're reading. That's one of Go's strengths.

This is, IMO, one of the things that makes Go exceptionally well suited to enterprise development: software tends to pass around multiple different teams with widely varying skillsets, and tends to have a surprisingly long shelf-life.

A simple language with enforced formatting means the code that I wrote several years ago looks much like the code I'd write today. Vendoring dependencies means I can ensure my environment works today as it worked when the application was being developed, and I don't need to go hunting for old dependencies that may not be there anymore. Lots of batteries included in a standard library that has a strong backwards-compatibility pledge means I often don't need libraries.

I've never worked with Go outside of an enterprise; I wonder if these pieces are maddening there.

> software tends to pass around multiple different teams with widely varying skillsets

I find this to be the most damning drawback: by design you can't ever get better with it, to cater to people who shouldn't be in the profession. There's a reason that using a spoken language clearly and eloquently is beyond the skill of a young child.

I agree that vendoring is the right solution for libraries that are not packaged for your target platform, in fact it's damn hard to reach truly deterministic offline builds without vendoring.

I don't use Go, but I agree with you. Style just shouldn't be an interesting topic, pick one and go. Best if the computer just handles it for you. Doing it this way gets everyone in the ecosystem on board with one style early on, and makes it much less of an issue going forward. This is the smart way to do it.