[zzzcpan]

> Interfaces in golang ... provide a better solution to that

Hm. What exactly are we talking about here? What problems inheritance and interfaces attempt to solve?

I mostly see abuse and overuse of interfaces in golang. It takes way too much time to understand what's going once you have an interface somewhere. The code starts to feel awfully OOish. You start guessing and assuming things, because you get that virtual thingy and finding what's behind this thingy and where is too much effort, you also have to get out of context. OO programmers have IDEs to help with that, but golang is anti-IDE. As a bonus you get that evil OOish style of manipulating internal state from a whole bunch of different methods that call other methods that change state. I guess they like to follow DRY dogma or whatever. Anyway, I don't see how interfaces are better than OO.

[bunderbunder]

In my experience, implementation inheritance always makes the problems you complain about worse, not better. With implementation inheritance you've got to go and trace a class's entire inheritance hierarchy all the way back to the root if you want to reason about a method's behavior. With interface inheritance the number of implementations you need to look at is always 1.

More generally, interfaces give you a way to provide an absolute minimum in semantic guarantees down toward the root of your inheritance hierarchy. This is critical if you want to follow the Liskov substitution principle. And you should always want to follow LSP.

[zzzcpan]

> With interface inheritance the number of implementations you need to look at is always 1.

Well, I haven't seen real need for neither of them. Both seem to only make things worse, not better.

[Profpatsch]

Exactly. It’s what I commented about super after 8.

You spread your (probably stateful, imperative) logic over several files and classes.

[zzzcpan]

> You spread your (probably stateful, imperative) logic over several files and classes.

It's just as awful in Go code that uses interfaces. State changes are still scattered all over the place. You still have to keep a model of everything in your mind to understand what some method does and what states it changes and what effects those changes have on other methods and so on. My point is: interfaces don't offer noticeable improvements over inheritance.

Building abstractions around state changes instead would be much better way, especially considering that Go supports function literals and closures. But nobody does that :( People prefer to abuse interfaces.