> Go might not provide built-in support for classical inheritance, but that doesn't prevent you from rolling your own:

What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile. There is no inheritance in Go, and you cannot roll you own.

> What Go doesn't make possible is tying inheritance to subtyping

There is no subtying whatsoever in Go to begin with. There is no point in "inheritance" if it is not polymorphic. What you just did is create a new type. that is not inheritance in a statically typed language.

> What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile.

That is called “subtyping”, not “inheritance”. Java and C++ happen to conflate the two concepts, but it's perfectly possible to keep them separate.

> There is no subtying whatsoever in Go to begin with.

A struct is a subtype of every interface its methods are compatible with.

It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism. you can't pass your "subtype" to a function that expect the parent type. You can absolutely pass a sub class in place of a class in a method expecting the class in Java. See the difference ? what you suggested makes absolutely no sense in Go. That's not even subtyping, you just created another struct type with composition.

> It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism.

I never said that struct embedding creates a subtype. I said that it can be used to emulate inheritance (subclassing). Inheritance and subtyping are very different things, and the fact languages like Java and C++ conflate them actually creates several problems. See:

[0] http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping9...

[1] http://stackoverflow.com/a/23592298/46571