I'm not going to speak for the whole Go community, but most people I've talked to in the community has eventually agreed that a lack of generics make code harder to write (after giving them some examples and showing them how other languages made this problem much simpler). That wiki page is quite a bad way of asking for feedback for two reasons:

1. It ignores the fact that most people who encounter a language problem will rather just work around it and make uglier code "because they have to" than to write a several-page dissertation on why generics would've solved their problem. Heck, some programmers haven't used generics before and don't realise that your code can become much simpler if you use them correctly. When I first found out that I could define a trait on a generic container type in Rust, I was massively surprised and realised how much unnecessary Go code I'd written recently because this one feature was missing.

2. It assumes that the programmers who complained about all of these issues in Go 1.0 several years ago are still sticking around, and can be bothered to reiterate the same arguments they made all that time ago (and were ignored all that time ago). Asking for more comments may sound like a "nice thing to do", but if you already burned the goodwill of the larger programming community with similar stalling tactics, then people are going to be less likely to be willing to help again.

I will give you some examples that have personally bitten me. The most frustrating part is that Go _does_ have generics, except that they are restricted to only be used by builtin types. make, new, len, cap, etc are all generic functions for the builtin collection types. But here are some examples:

1. Collection types are effectively impossible to implement usefully. []T will not be promoted to []I if T is a type that implements an interface I. This requires creating a new slice in memory and doing a noop cast (the same applies to arrays and maps). As a result, creating a generic sort implementation won't work. Yes, Go has a "sort implementation"[1] but rather than requiring something like []Ordinal you have have the _slice type_ implement Swap and Compare. Just look at how bare the container package is (and note that they require you to implement all of the core features of the container yourself). In a language with generics such as Rust (or even Java) this interface would be considered ridiculous, but in Go it's the only way of giving some kind of generic functionality (even though it's not actually generic in any sense of the word -- you have to implement all of the common code manually even if it is structurally identical).

2. Everything that wants to be generic in some sense devolves into using interface{} to represent "something that I will use reflection to introspect". However, the reflection API is far from good, and there are cases where because there is an interface{} type in the way, you cannot mutate something that you would be able to mutate if you didn't have define things as interface{} (an *interface{} doesn't allow you to modify the underlying type through reflection as far as I could tell). Admittedly, I have done some very dodgy stuff with Go's reflection API, but that doesn't mean it's a good API.

3. The workarounds for generics have reached the point where some people created tools that generate code that implements a "generic type" by manually generating the code for each type. This is something that compilers for languages that have generics do _automatically_, but in the Go universe you have people so desperate for generics that they are re-implementing something that should be a compiler feature as part of their build pipeline. I personally don't use any of those tools, because after trying several of them I realised that they make your code even harder to understand because all of the type information is generated in a way that obscures what you're actually trying to do.

The only reason I write Go code is because (for some misguided and other justified-at-the-time reasons), the majority of the container ecosystem is written in Go and it's not reasonable to switch to anything else. A bunch of other developers and I have been looking at switching over to Rust, but there is a lot of inertia in keeping everything in one language. But if you saw what fairly horrific shit Kubernetes had to do in order to emulate generics with reflection, you would likely want to run for the hills.

[1]: https://golang.org/pkg/sort/
[2]: https://golang.org/pkg/container/