One thing that really surprised me about Go — a supposedly simple language — is that you can even do multiple inheritance. And it’s pretty bad. Someone on the

One thing that really surprised me about Go — a supposedly simple language — is that you can even do multiple inheritance. And it’s pretty bad. Someone on the golang-nuts mailing list discovered, that Go doesn’t handle inheritance ambiguities very well. I have adapted the code mentioned therein so that it also showcases the well-known ‘Dreaded diamond problem’: Effective go [1] has this to say about embedding, and if you follow the rules, the results of the demo code don't seem surprising to me - it just takes the least deep 'foo'. Embedding types introduces the problem of name conflicts but the rules to resolve them are simple. First, a field or method X hides any other item X in a more deeply nested part of the type. Second, if the same name appears at the same nesting level, it is usually an error; it would be erroneous to embed log.Logger if the Job struct contained another field or method called Logger. However, if the duplicate name is never mentioned in the program outside the type definition, it is OK. This qualification provides some protection against changes made to types embedded from outside; there is no problem if a field is added that conflicts with another field in another subtype if neither field is ever used. Also, to me it looks more like composition over inheritance. Not sure if that's what he means by multiple inheritance. Maybe thinking about it in terms of properties finding it's way up rather than inheritance being passed down makes more sense anyway. [1] https://golang.org/doc/effective_go.html#embedding https://golang.org/doc/effective_go.html#embedding