"Frankly, people make too big a deal about generics." I think there's a lot of confusion brought in from languages where generics are a bigger deal than they a

"Frankly, people make too big a deal about generics." I think there's a lot of confusion brought in from languages where generics are a bigger deal than they are in Go, because when generics came in to those languages it was like turning on a light. However, if you map out the problem space of "what did generics solve in those languages", rather than obsessing about the solution, what you find is that Go's interfaces, combined with the structural typing ("static duck typing" basically, rather than having to explicitly declare conformance at declaration time) covered quite a bit of the problem space. And that's what matters, whether the problem space is covered, not whether the problem space was covered in exactly the same way as some other language. People who either have never programmed in Go, or only spent long enough with it to try to program "(Not Go) in Go" (e.g., "Javascript in Go"), and didn't learn how to use the tools Go has to cover the problem space, end up vastly overestimating their utility in Go, and vastly overestimating the sort of problems you can't use Go to solve. They're like "How can you program in a language that doesn't cover the 'generics' problem space?", and the answer is, "You're actually right, I couldn't! But I can use Go, because it actually does cover quite a bit of the problem space, just in a different way than what you're demanding." Interfaces DO NOT cover all the space, I would never dream of claiming otherwise, but they cover a lot of the space. There's even some problems where I've found Go simply outright the best solution because of some particular thing I can use interfaces to solve. I'll actually kind of miss the "How can I do this without generics in Go?" questions on /r/golang. They're fun, and with the exception of "data structures", generally I didn't just come up with "a" solution, but with a good solution.