Appendix 1: Composition, not inheritance

A key difference in the philosophy behind both Unix and the Go language are a concept called composition. Composition is where a language allows you to embed structures and interfaces into other structures and interfaces, and for convenience, where there is no name collision, you can access inner methods as though they were inherited methods. But they are not. And sometimes it's better to be specific, especially for cases where you have two types with colliding methods that really need a different term anyway for the composite action (such as delete on an immutable log, a tombstone rather than erasure).
This is a strong influence on the architecting work done in the IPFS/libp2p/multiaddr codebases and APIs. It is not so familiar and many who are soaked in OOP philosophy are hostile to what seems to be a regression back to C, if you can put it that way. Java programmers and Python programmers are the most likely to understand the idea, really it's just a namespace syntactic sugaring, but it eliminates the rigidity of classes. Lets you make everything read, or write, or persist data, or encode and decode data, even that simple, without having to think about that until you have the thing in front of you, which is much more practical considering how one combinatory change can unsettle a whole ontology. With composition you can make chimeras. To make it sound cool to fantasy/scifi nerds.