I can sympathize with this concern; constraints can force authors to just write simpler code which has some very nice benefits. But that leaves out some legitim

I can sympathize with this concern; constraints can force authors to just write simpler code which has some very nice benefits. But that leaves out some legitimate use cases like collections that were terribly served by genericless-go. Yes there will be some pockets of libraries where authors take generics to an extreme. Besides being a bit of fun, it's good to explore the edges of what you can do with the language, so this exercise will be valuable even if you don't use them regularly in your projects. But I don't really see pervasive gratuitous use of generics becoming a big problem for the average lib, Go devs tend to lean practical on potentially abused features like this, and there will be many users like yourself that will still prefer simpler interfaces. I guess we'll see over time. Really, Go's lack of generics for so long wasn't an ethos (despite many taking it that way) but more that the right implementation just hadn't revealed itself yet. I think the one they chose is a pretty good match for Go, and I hope that it makes Go more complete.