But "company wide linters" do carry over to other companies and projects. For Go its already set up, you dont have to think about it. Otherwise youll have a week (or more) discussion for every single quirk in the language and how one would format that and try to apply this to a group of people.

I'd call them more like working standards. Imagine having to discuss how to make a brick wall everytime you need to make one. Things like having a masonry cord (which can equal to a "gutter", line length restriction) and the mixture of the cement, are critical for execution in a team of more than 1 person, and not following standards will make a hacked up job.

> On the other hand, same thing can be accomplished by using company-wise style enforcers

But you can't do that with open-source libraries. When I use an open source library, I can audit its code very easily, and this is not always true with other languages. The more complex the language, the harder it is to audit it. There are many C++ open source libraries (hello Boost) I can't understand because they don't use the dialects I'm used to.

This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head:

Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.

Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.

Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.

Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.

I dunno, I feel like Go was created to commoditize the work of programmers. Make everyone write the same stupid and repetitive code, over and over again. No one will ever be able to fuck it up, and no one will ever do anything interesting with it. You can onboard new hires who don't know the language in literally an hour. When reading the code, everyone will understand what each line does but there will be so many lines in the codebase that most people won't actually have time to understand the entire project (which is probably how the managers prefer it, actually). The performance will be pretty okay, since the language isn't high level enough to not be aware of the performance of the code you're writing. Great for companies with a gazillion coders. Like Google.

Programming in Go is like trying to tie your shoes with one hand. You can do it, and its okay (I guess), but you can always see how things could be so much easier.

Maybe this is a bit much, but I find Go offensive: designed for the maximum amount of typing and least amount of thinking. Even Java looks like a powerful language in comparison.