I think the reasoning is that for something that's commonly used for many different types, you won't go through the effort of re-implementing that function for each type (it may not even be feasible to do so). Which means you'll end up with some sort of indirection to make it generic.

The point is they shouldn't be slower than a manually-copied implementation for that concrete type. They also should be faster than vtable dynamic dispatch in the vast majority of cases. (I also fail to see a compelling reason that they couldn't have been implemented by passing the fat pointer directly, making the codegen the same as passing an interface, instead of having that business with the extra layer of indirection.)

If there are specialization opportunities when hand-implementing the function for a given concrete type, I would indeed expect that to be faster than a monomorphized generic function.

> I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype.

The point is that a monomorphized generic function should not be slower than the custom-function-per-datatype, but because Go's generics are not fully monomorphized they can be, and in fact can be slower than the a function-for-interface.