Define "direct support" for inheritance. IMO, a symbol named inherit doesn't have to exist for there to be inheritance.

Here is a blog post answering your exact questions: http://areyoufuckingcoding.me/2012/07/25/object-desoriented-...

Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...

I come from C++ background, so by "direct support", I think he means a language construct that clearly shows the inheritance relationship, as in

Java:

       public class MountainBike extends Bicycle

or C++:

      class MountainBike: public Bicycle

From those links, it looks like in Go, you use an anonymous struct inside a normal class. I would call it "aggregation" or "containment" (or implicit delegation), not inheritance. It suggests "has-a" relationship rather than an "is-a" relationship. The Go's "syntax" for inheritance (if you can call that) is ambiguous, unlike C++ or Java.

I don't see any downsides to this though, could you enumerate any you can think of? For instance, I believe I an model relationships either way and accomplish the same thing with little to no difference.

Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.

FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.

It does have inheritance although the syntax is different:

  type SubClass struct {
    SuperClass
    other fields...
  }

That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding

So, according to this logic, even C is Object-oriented with support for inheritance, because:

     struct SubClass {
        struct SuperClass super;
        // .. other fields ...
     }

is valid.

So Go has embedding not inheritance because SubClass is not an instance of SuperClass, there is no hierarchy, only composition.

BUT what you might not realize is that any method defined on SuperClass (and only defined on SuperClass) can be called on SubClass, but it operates on SuperClass data. This allows SubClass to use SuperClass to help it fulfil an interface for example.

See it in action: http://play.golang.org/p/8kiwu1PlW_

This is similar to C++ in which base class methods are 'virtual'. Is there a way to stop this behaviour? Just thinking how non-virtual methods can be implemented then. C++ has a keyword, 'virtual', for switching this behaviour, but any analogue in Go?

You mean like final in Java? I don't believe there is. Go has a different way of handling OO and so far I have never needed "final". In Go embedding is not common and interfaces are used much more.

In Go, having final in an embedded struct affect the containing struct seems wrong IMHO- this would allow embeded fields to dictate the behaviour of things that embed them. I don't think most programmers would be happy with adding a field to a struct and as a consequence be prevented from implementing a given method signature.

Ah sorry, I have no idea about Java or final, so ... can't comment.

I don't think you really understood the Go example. In C if I have:

    struct SuperClass {
        int foo;
    };
    struct SubClass {
        struct SuperClass super;
    };

Then to set the foo item I'd have to do: struct SubClass bar; bar.super.foo = 5;

Whereas in Go I could say: type SuperClass struct { foo int } type SubClass struct { SuperClass } bar := SubClass{} bar.foo = 5

So, small difference, but I think valid.

Go try calling SuperClass's method on Subclass, and tell us the two problems you face.

Embedding is not strictly the same thing as inheritance.