[lhorie]

Here's a different (and potentially offensive, please put away the pitchforks) perspective. Recently at work, I was prompted by a coworker to look at a code review page for some go code they wrote. I don't normally review go code at work, so something that struck me was that the code review comments left by a go developer seemed quite a bit more nitpicky than code reviews I'm used to seeing as a non-go developer working with non-go languages. A lot of it was minor stuff like styleguide line items (isn't that sort of stuff what go fmt and go vet are for?)

Golang is an extremely simple language (a good thing, IMHO!), but that means two things:

1) a simple language may lack safety features (e.g. anyone can ignore an err or forget to check for nil pointers), which lead to the need to compensate in other ways, which leads to:

2) the bikeshedding bar is very low in simple languages, and it can lead to institutionalizing opinions in the form of styleguide gospels or other types of "improvements" (think overuse of patterns in Java, another relatively simple language), to the point where the institutional rules put off newcomers who were expecting a breath of fresh air but instead find an "old boys club" (in the sense that they don't feel they have leverage to discuss whatever rules have been set).

I also see this phenomenon in other areas, for example, in Javascript, eslint/prettier are supposed to curb bikeshedding, yet there's an awkward dynamic when a new employee wants a new rule, and what follows is 2 hours of bikeshedding with the old guard.

[AlchemistCamp]

Prettier lost me forever over how they handled the issue of massive (IMO correct) pushback over not allowing "break before else".

Mozilla got it right on that one.

Setting aside "right" from a technical perspective, the Prettier response to the issue was very, very disappointing.