The sense I've gotten is that the Go team is surprised how little complaint has arisen among actual Go users about the lack of generics, and that that has kept the priority level low for figuring out how to implement them. In other words it seems like the Go team is actually slightly more interested in having them than the user base is.
I'd like them in part because it'd enable all kinds of delightful reactive functional idioms that just aren't very possible currently. On the other hand I'm accomplishing an awful lot in Go without them..
I don't care too much about the "delightful functional idioms" (on the grounds that merely adding generics to Go will still leave us pretty impoverished on that front anyhow) and doubt the Go team does, either. Probably the biggest and most visible pain point of missing generics is here: http://golang.org/pkg/container/ In particular, the pain point is that there aren't very many things there.
Missing generics does not mean that no alternate data structures ever get written; as you can see, there are three of them there, which is greater than zero. However, it does mean they are more painful to use, consistently, everywhere, and no matter how much we'd all like to pretend we are infinitely disciplined programmers, pain matters, and in practice programmers visibly shy away from harder things. It is simply a fact that we must deal with. Generics missing from the language are a problem because it means that doing the right thing is harder than doing the wrong thing of just, say, using the wrong data structure because it's more convenient. A language (or an API or a library) should make right things easier and wrong things harder; it is a legit criticism when the right thing is impossible and the wrong thing (extensive copy & paste) is the only choice.
Maps & slices are great and all, but they do not correctly cover all use cases, and the sort of servers that Go is otherwise very suitable for is also exactly where you might end up needing something other than those two things for performance reasons.
I'm living without generics in Go, of course, because everyone programming in Go is. But I definitely see a lot of places here and there where I'm writing 5 lines extra, 10 lines extra, here, there, a little bit everywhere, that I simply should not have to write. Or, far worse, debug. Too often in Go I'm copying & pasting code where I should have generics, too often I'm fiddling with data structures at a lower level than I really need to.
Interesting, sounds like this could lead to everyone using the built in Go types even where they are not optimal, the way some old Lisp programs modeled everything as lists.
I'd like them in part because it'd enable all kinds of delightful reactive functional idioms that just aren't very possible currently. On the other hand I'm accomplishing an awful lot in Go without them..