Copying is encouraged. Like I said, having the algorithm there is a good way to make it apparent what the code is actually going to do and the associated cost of the solution.
interface{} could be avoided by having an interface that reflects the behavior you actually need from the types involved in the algorithm. If you need to only test for equality, you could have an algorithm that works on []Eq. That is one of the downsides to Go, unlike Haskell, interfaces are usually defined by the consumer, which makes negotiating common interfaces like Ord and Eq difficult.
>Copying is encouraged. Like I said, having the algorithm there is a good way to make it apparent what the code is actually going to do and the associated cost of the solution.
In 2019, having a generic implementation of the algorithm is also "a good way to make it apparent what the code is actually going to do and the associated cost of the solution" in most languages.
On top of that, it helps you have less code (easier to check, code is a liability), skip manual text-template-generated code pre-process steps, let's you code what you know you want without a context switch to copy something that you've already written for another type, and stop bugs stemming from e.g. changing things in one implementation of the same algorithm and not another (because you're forced to have 10 implementations for different types).
And copying has been an anti-pattern since the times of Algol. Except if it's replaced by the "wrong abstraction" prematurely. But nobody ever called having a generic version of an algorithm "the wrong abstraction".
I know Go encourages copying code, but that is a well known anti-pattern in all other language communities,one of the few with some research behind it (as someone else mentioned, basically the only quantitative science we have on software engineering says that more code implies more bugs).
The idea of []Eq sounds nice, but again, the problem is that I can't pass an []X to a function that wants an []Eq, I need to build a new array and copy all my elements over. This is correct from the type-theory point of view (as slices are not covariant) , but of course Go doesn't offer anything else that would be more user friendly and still correct, such as a covariant read-only slice that we could use instead.
> Copying is encouraged. Like I said, having the algorithm there is a good way to make it apparent what the code is actually going to do and the associated cost of the solution.
It's also a good way to make bugs proliferate throughout your code base. IIRC bug count correlates well with line count regardless of the language(!).
interface{} could be avoided by having an interface that reflects the behavior you actually need from the types involved in the algorithm. If you need to only test for equality, you could have an algorithm that works on []Eq. That is one of the downsides to Go, unlike Haskell, interfaces are usually defined by the consumer, which makes negotiating common interfaces like Ord and Eq difficult.