> you would need to have effectively two generics implementations, one working at runtime and one working at compile time
replyMy understanding is that go already has a hybrid system works at compiletime and sometimes at runtime.
I'm not sure what you mean. Perhaps you are referring to the reflect package? In that case, yes, that exists. But it is limited in its power (for example, it doesn't allow to create types with methods – precisely because of the difficulties we are talking about) and a comparatively frequent source of bugs. If anything, it provides pretty strong evidence for the problems with this approach.
replyhttps://go.dev/doc/faq#generics_implementation
replyMy point is for interface generics it could just always use a single instantiation. Similar to what java does.
Or alternatively, go could go the other direction and add a new type of interface that is only for use in generic constraints, and then generic methods could be part of that interface, but not normal interfaces, so that the generic methods could be called from other generic functions. That would be similar to rust and c++.