Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.Um... OK, so you have this sort of loosey-goosey approach to interfaces (if I have the methods, I satisfy the interface), but what about super class constructors and concrete (non-abstract) methods? I'm having trouble imagining libraries such as UI toolkits (WPF, Flex, Swing, etc.), which effectively make heavy use of relatively deep inheritance trees, being written in as elegant a manner in Go. Those super classes are doing a lot of work, and the type hierarchies provide a nice taxonomy for the API. Perhaps Go is advocating the use of a different paradigm to accomplish the same thing, but it doesn't seem to be readily evident from the docs.