What frustrates me a bit about this argument is that interfaces really do offer a tool to solve problems around dispatch and polymorphism. Like a lot of things

What frustrates me a bit about this argument is that interfaces really do offer a tool to solve problems around dispatch and polymorphism. Like a lot of things in Go there are lots of opinions and tradeoffs that can’t or can’t easily be revisited by someone using the language, but it’s a very different argument to say “I don’t like the tools the language provides” than “the language doesn’t provide x, y, z”. IMHO there are convincing arguments that Go needs x, y, z (or: prefer another language if you need x, y, z). A good example of one of these that is being addressed would be priority queues. Doing them via interfaces was always possible - there’s a whole std lib package for them. Generics will be better. But looking at the pre-/post-generic ways of doing priority queues confirms and emphasizes, rather than negates, the utility of interfaces as a way of structuring code. It’s still opinionated and I think it’s fair to argue about alternatives but it’s absolutely not the case that some large class of reasonable problems was entirely ignored or forgotten.