[torben-friis]

In case the question isn't facetious:

Go's main advantage, IMO, is that is both simple and opinionated to the extreme. It's a language that makes a lot of choices for you (from "no while loop" through "no exceptions" to where the brackets go formatting the file). Those choices might be the best choice or not, but the point is that they're already made and they're enforced.

The result is that in a big company, all projects made in go are very similar to each other in a lot of ways (much more than the average language) and so it is as easy as possible to have people contributing in each other's projects or moving between teams. There's no arcane syntax, no discussion about linters, nothing like that.

It's basically an amazing language to make programmers interchangeable. Whether that's good or not is a different discussion, but at the very least it looks that it's gonna make it very attractive for employers and so be a highly demanded skill in the near future.

[sytelus]

This is very weak argument. Once these restrictions are embedded in language, it cannot be removed by anyone. On the other hand, same thing can be accomplished by using company-wise style enforcers. If you think that is harder, I'd say forcing every project in big company to use same language is even more harder.

My main quip with Go is that its rather more of the same but more poorly done in the name of minimalism. Extreme minimalism is as bad as extreme richness. The entire art of language design is achieving just the right balance for a specific audience and set of goals.

[diamondo25]

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.

[diamondo25]

s/do carry/do not carry/

[sacado2]

> 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.