My understanding is that in Haskell, all instances of type classes are explicitly declared. They don't have to be declared at the type declaration, but they must be explicitly declared. Unlike Rust, Haskell does allow orphan instances, so you can approximate some of the flexibility of structural typing, but it's still not structural like interfaces are in Go.
That's a significant difference in the design space. And, in particular, it makes generics harder. With explicit instance declarations, you have a natural place to define the type parameters of the instance itself and then specify how those map to the type arguments of the type class being implemented. With implicit interface implementations, there's no place for association to be authored.
I'm not saying Go's solution is better or worse, just that it's not them half-assed cribbing type classes. It's a deliberately designed different feature.
(My actual opinion is that I think interfaces in Go are more intuitive for users and easier to learn and use, at the expense of losing some expressiveness for more complex cases. Whether that's the right trade-off depends a lot on the kinds of programs and users the language is targeting. In the case of Go, I think that trade-off makes sense for their goals.)
I get so tired of functional programmers claiming to have invented everything first and assuming that what other languages do are just failed imitations instead of deliberate differences with important subleties they are overlooking. In particular, in these kinds of discussions, the "Haskell/Lisp/Smalltalk did it first" folks rarely take into account trade-offs, usability, or context when evaluating features.
We can't lump Lisp and Haskell into the same category. Whenever Lisp did something first, it was always easy to understand and use, compared to the twisted reinventions. The reinventions are Jack Skellington's imitation of Christmas.
About the only criticism you could lob at the Lisp original feature would be some low-brow grumble about parentheses.
Yes, because naming core operations in the language after assembly instructions in an ancient IBM vacuum-tube computer because they are incidentally how those operations happened to have been implemented once is the height of clarity.
That's a significant difference in the design space. And, in particular, it makes generics harder. With explicit instance declarations, you have a natural place to define the type parameters of the instance itself and then specify how those map to the type arguments of the type class being implemented. With implicit interface implementations, there's no place for association to be authored.
I'm not saying Go's solution is better or worse, just that it's not them half-assed cribbing type classes. It's a deliberately designed different feature.
(My actual opinion is that I think interfaces in Go are more intuitive for users and easier to learn and use, at the expense of losing some expressiveness for more complex cases. Whether that's the right trade-off depends a lot on the kinds of programs and users the language is targeting. In the case of Go, I think that trade-off makes sense for their goals.)
I get so tired of functional programmers claiming to have invented everything first and assuming that what other languages do are just failed imitations instead of deliberate differences with important subleties they are overlooking. In particular, in these kinds of discussions, the "Haskell/Lisp/Smalltalk did it first" folks rarely take into account trade-offs, usability, or context when evaluating features.