He means that where you’d use something on the order of:

class A : public B {};

in something like Java or C++, in Go you’d use (something equivalent to):

class A {
    B b;
};

Yes, this provides inheritance-like capabilities. Let’s expand the example above a little bit:

struct B {
    int foo() {}
};

struct A { 
    B b;
};

A a;

a.foo();  // not allowed in C++ or Java, but allowed in Go.

To do this, however, you use a syntax that’s not allowed in C++ or Java — you leave the embedded object without a name of its own, so it’s more like:

struct A {
   B;
};

This question/problem is kind of similar to this one.

In Go, you don’t really have OOP.

If you want to “specialize” an object, you do it by embedding, which is a composition, but with some goodies making it partially similar to inheritance. You do it like this :

type ConnexionMysql struct {
    *sql.DB
}

In this sample, ConnexionMysql is a kind of specialization of *sql.DB, and you can call on ConnexionMysql the functions defined on *sql.DB :

type BaseMysql struct {
    user     string
    password string
    database string
}

func (store *BaseMysql) DB() (ConnexionMysql, error) {
    db, err := sql.Open("mymysql", store.database+"/"+store.user+"/"+store.password)
    return ConnexionMysql{db}, err
}

func (con ConnexionMysql) EtatBraldun(idBraldun uint) (*EtatBraldun, error) {
    row := con.QueryRow("select pv, pvmax, pa, tour, dla, faim from compte where id=?", idBraldun)
    // stuff
    return nil, err
}

// somewhere else:
con, err := ms.bd.DB()
defer con.Close()
// ...
somethings, err = con.EtatBraldun(id)

So at first sight you might think that this composition is the tool to make your usual taxonomy.

But

if a function defined on the *sql.DB calls other functions defined on *sql.DB, it won’t call the functions redefined on ConnexionMysql even if they exist.

With classical inheritance, you often do something like this :

func (db *sql.DB) doComplexThing() {
   db.doSimpleThing()
   db.doAnotherSimpleThing()
}

func (db *sql.DB) doSimpleThing() {
   // standard implementation, that we expect to override
}

That is, you define doComplexThing on the super class as an organization on calls of the specializations.

But in Go, this wouldn’t call the specialized function but the “superclass” function.

So, if you want to have an algorithm needing to call some functions defined on *sql.DB but redefined on ConnexionMySQL (or other specializations), you can’t define this algorithm as a function of *sql.DB but must define it elsewhere and this function will only compose the calls to the provided specialization.

You could do it like this using interfaces :

type interface SimpleThingDoer {
   doSimpleThing()
   doAnotherSimpleThing()
}

func doComplexThing(db SimpleThingDoer) {
   db.doSimpleThing()
   db.doAnotherSimpleThing()
}

func (db *sql.DB) doSimpleThing() {
   // standard implementation, that we expect to override
}

func (db ConnexionMySQL) doSimpleThing() {
   // other implemenation
}

This is quite different from the classical overriding of class hierarchies.

Especially, you obviously can’t directly have a third level inheriting a function implementation from the second one.

In practice, you’ll end using mostly (orthogonal) interfaces and let function compose the calls on a provided implementation instead of having the implementation’s “superclass” organizing those calls.

In my experience, this leads to the practical absence of hierarchies deeper than one level.

Too often, in other languages, you have the reflex, when you see that the concept A is a specialization of the concept B, to reify this fact by creating a class B and a class A as a subclass of B. Instead of creating your program around your data, you spend time reproducing the taxonomy of objects in your code, on the principle that this is reality.

In Go you can’t define a general algorithm and specialize it. You must define a general algorithm and ensure it’s general and works with the provided interface implementations.

Having been horrified by the growing complexity of some hierarchy trees on which the coders were making complex hacks to try to accommodate an algorithm whose logic finally implies all levels, I’d say I’m happy with the simpler Go logic, even if it forces you to think instead of just reifying the concepts of your application model.