Constraints in Go

That's kinda the point. Generics are mostly a library concern, improving end-user experience and performance. End-user creation of generic types is relatively rare, and you can use them in very simple ways and that's almost always good enough because you don't need them to be maximally correct, only good enough.

For libraries (that adopt generics): yes they can be complicated. But using them is mostly zero-effort and gets rid of a ton of reflection.

Unfortunately not everyone shares that opinion of their restricted use-cases.

I've seen ~100 line HTTP handler methods that are implemented using generics and then a bunch of type-specific parameters inevitably get added when the codepaths start to diverge and now you've got a giant spaghetti ball of generics to untangle, for what was originally just trying to deduplicate a few hundred lines of code.

tbh I'll still take it over a similar Gordian knot with interfaces. At least you can tell the restrictions are met at compile time, rather than silently failing at runtime because you (and/or someone else in the past) didn't notice one edge case lodged somewhere surprising.