Embedding instead of inheritance in Go

In a comment, you wondered if the embedding idea was enough to "replace inheritance completely". I would say the answer to that question is "yes". A few years ago I played very briefly with a Tcl OO system called Snit, which used composition and delegation to the exclusion of inheritance. Snit is still vastly different from Go's approach, but in that one respect they have some common philosophical ground. It's a mechanism for joining together pieces of functionality and responsibility, not a hierarchy for the classes.

As others have stated, it's really about what kind of programming practices the language designers want to support. All such choices come with their own pros and cons; I don't think "best practices" is a phrase that necessarily applies here. We will probably see someone develop an inheritance layer for Go eventually.

(For any readers familiar with Tcl, I felt Snit to be a slightly closer match to the "feel" of the language than [incr Tcl] was. Tcl is all about the delegation, at least to my way of thinking.)

Embedding provides automatic delegation. This in itself isn't enough to replace inheritance, as embedding provides no form of polymorphism. Go interfaces do provide polymorphism, they are a bit different than the interfaces you may be use to (some people liken them to duck typing or structural typing).

In other languages, inheritance hierarchies need to be carefully designed because changes are wide sweeping and therefore hard to do. Go avoids these pitfalls while providing a powerful alternative.

Here's an article that delves into OOP with Go a little more: http://nathany.com/good