Go already has generics for its built-in collection types, yet you can see nothing but downsides for user-defined generic types?

Incredible mental gymnastics you've got there.

It's the number one reason I tried out but wouldn't return and do anything serious in the language. And I'm not the only one.

There are numerous successful "serious" projects written in Go!

Many companies also had successful "serious" projects in Algol, Pascal, Basic, Forth, you name it.

The world of programming languages has improved since then.

Of course there are, but I wouldn't want to be the one to write them.

OK - well, from my 4+ yrs of experience creating and maintaining a big Go project, take it from me that it's really a very pleasant and productive language. I am branching out and learning Rust as an intellectual exercise, but can't help but think about how obtuse its syntax is compared to Go. I will continue to choose Go in the future just because it's so quick to work with (while also providing solid safety and refactoring support). The `interface{}` thing rarely comes up as a problem.

It's not just the interface{} thing that's annoying. From my point of view, Go has way to many annoyances to be decent. No constness. No protection against copying. No compiler warnings. Crap error handling. Public/private denoted by uppercase/lowercase letter (WTF?). Implementation details leaking into the language - such as the "typed nil" nonsense. Struct and interface embedding is insane. Multiple returns from functions but no tuples. Needlessly complex `for` syntax, needlessly complex receiver syntax. Needless magic channel operators (they could've easily just been functions).

The tooling is also annoying with the most glaring deficiency being the lack of package versioning, which I believe is going to change (or it has already? I don't remember). And then there are tools like `go vet` which basically just attempt to make up for the compiler deficiencies in sub-par ways...

Go has a very nice runtime, but the language itself and the tooling feels extremely half-baked. I'm curious whether Go 2 will improve upon this.

All very valid points. I think most of those features were omitted for the sake of simplicity by the Go team. Many people disagree with that.

Yes, the people who want generics are either people who don't use Go, or don't understand the purpose of Go and the implications of adding them to the language.

Great way here to completely discount the criticisms of people who've used the language and found it unacceptable how often you have to escape out of the type system of a "safe" language with `interface{}`.

I've written Go for three years, and I've successfully avoided using interface{}. It's a matter of architecting your application to fit the language and choosing a different language if your requirements grow beyond what Go can provide. Golang has made a tradeoff between simplicity and abstraction, which is a perfectly fine choice. Turning Go into Java is just going to ruin yet another language with complexity thanks to mob mentality.

It's not always that simple. Sometimes you cannot avoid using interface{}. There is a reason why some SQL libraries use interface{}, why (un)marshallers use interface{}, and why I use it heavily in my scripting interpreter which is written in Go.

This is a rather elitist and blanket statement comment and is not at all fair. You do not know the mindset of "the people who want generics" but you're acting like you do to make a rhetorical point about how you feel about them. There are many more polite ways of making your case.

Exactly. Say goodbye to fast compiles and easy-to-read code. Not to mention the muddy waters that will result from having both interfaces and generics together.

Just imagine the peer-pressure strategies that must already be forming in community minds to deploy against Go 1.x loyalists :)