> The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}.
I see this repeated again and again. It's wrong.
The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type.
People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.
I knew about this solution. It's just that my inner Ruby dev screams "DRY!". Obviously it's so repetitive that it would be a bad sign in other languages.
I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines.
I see this repeated again and again. It's wrong.
The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type.
People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.