You're intended to run gofmt on every save. golang is designed to be a sort of straight-jacket that forces everyone to write code in the same way (style etc) so that the junior devs can understand it clearly.

And so that people (of any level) don't bikeshed over silly things like tabs and spaces or { and newlines.

I really like this about go - that it formats code for you, and miss it in other languages where we have linters but not formatters, which is a terrible idea IMO.

What mainstream languages don’t have formatters nowadays? Rust has rustfmt, C and related languages have clang-tidy, python has Black…

I mean built in that everyone uses. There are of course third party formatters.

You can force everyone on a project to use a formatter just as easily in any of those languages as you can in Go, with a few lines in your CI job definitions. Whether they're third-party or not is irrelevant.

It's not irrelevant, it's the entire point. The whole Go ecosystem uses a single formatter. There's no need to force anyone, everyone just uses gofmt. You will not be able to replicate that level of ubiquity easily at all.

Not really true because you have both gofmt and gofumpt, and gofmt can be run with -s or not, and also lots of projects are using separate linters to enforce maximum line length.

But true enough.

Not true. Because after running go fmt and pushing our CI fails because of other stylistic concerns that are checked by another tool.

You can only force everyone on a project to use a formatter if you are the one who has the authority to decree what will be done on the team. OTOH, if you are but a team member and you join a team where the manager does not think common formatting is important, then you get f*ck all.

So being built-in, idiomatic and expected cannot be over-appreciated.

that's your preference but not universal

My only preference is not to have to think about whitespace etc. I guess others who feel differently certainly wouldn't like Go, and that's ok!

Why are you talking about go fmt? I'm talking about parser of the go language

If I write

    if x
    {
    bla
    }

it will not compile, because the { needs to be on the same line as the X (for no reason whatsoever).

> The standard library is unimpressive (to be generous)

Coming from Python, this is one of the major things that I just can't get past with golang (despite having to use it for work). The standard library has a lot of really interesting/impressive/useful things to cover niche cases, but is missing a lot of what I would consider basic functionality that I keep running into requiring me to go get an external module to solve the problem.

Then, on top of that, the documentation for external modules is extremely terrible. In many cases the best you can get is API documentation in the form of "these are the functions, this is what they take and return" with no explanation of what those values need to be, what the function does with them, and so on; a simple list of functions. In others, there is that plus example code which doesn't work because it hasn't been updated since the last time backwards-incompatible changes were made so you end up down a rabbit hole of trying to debug someone else's wrong code.

The only thing letting me write effective golang at this point is that VSCode can autocomplete a lot of method calls, API calls, and so on, and then tell me what parameters they need, but even then I'm just guessing about what function might exist and what it might be called.

The language itself is okay and the more I use it the more I understand why they implemented all the stuff I hate (like a lack of proper error handling leading to half of my lines of code being boilerplate `if err != nil` blocks), but if the tooling around it wasn't so good no one would take it remotely seriously.