[snazz]

Go's mediocrity is a feature, since it's supposed to allow larger teams to get more work done. That seems to have worked fairly well in practice. The authors hypothesized that a inexpressive language might actually be superior for the types of things that Google used to do in C++ (in terms of development time including onboarding and defect rate [especially with regards to concurrency]).

Git's implementation is stronger and more useful for larger projects than Mercurial's, even if the user interface is less logical.

It's not that the software world is driven by hype but that the software world is driven by what the giants do. Often, what Google does isn't right for a small project.

[jcadam]

> Go's mediocrity is a feature, since it's supposed to allow larger teams to get more work done.

I get it. Most software is boring, doesn't break new ground, and Go is well suited for those kinds of projects.

But I'm becoming an old, cranky developer who wants to work on problems where Go's mediocrity is more hindrance than advantage.

[pjmlp]

Same was told of Java (blue collar language) and here we are 25 later where Go people consider Java a PhD level language, while the eco-system is trying to steer a battle cruise to learn new tricks that should have been part of Java 1.0.

Guess how Go will look like at 25?

[apta]

> since it's supposed to allow larger teams to get more work done.

Keyword being "supposedly", because in practice, it's quite terrible compared to established solutions like Java and C#.

[Constellarise]

> Go's mediocrity is a feature

Removing complexity from the language just moves it onto the developer and end-user code, it doesn't eliminate it. Go's mediocrity is a ticking timebomb.