As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
> Even the author of Java, James Gosling, disagrees with you.
From the article:
> Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
Key words: preferable, and whenever possible. It's sometimes preferable to have inheritance and not possible to leave it out without unneeded extra complexity.
Furthermore, nowadays interfaces in Java (as well as Kotlin, Scala, C# - all of which are much more expressive and have superior modeling capability than golang) can have default implementations, which increases their application even more and reduces the need for explicit inheritance. Not so in golang since interfaces cannot have default implementations there.
> As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
Not quite, it's just where having inheritance would have simplified the design, and improved readability.
He quite clearly states in the article he would ‘leave out classes’ (i.e. implementation inheritance). You didn’t quote the clearest statement in the article, just preceding your excerpt!?
Again on interfaces, sometimes less is more. Many people prefer the inverted interfaces of go, declared at point of use. It’s fine to prefer the opposite, but these are deliberate choices, not mistakes or failures.
Re inheritance simplifying a design, it does the opposite in my experience, unless by simplify you mean hide program flow and state.
The implication of "whenever possible" is that an OO language should strive to maximize this metric - for example, by making composition easier (e.g. providing syntactic sugar for "implement this interface by delegating all methods to this object").
But yes, Go is definitely worse in that respect, not better.
