I was reading the Go-lang documents and found under the section of Types that Go has no type hierarchy.

What does that mean exactly? Is it like python that types are been checked at run time (dynamically typed) rather than 'compile time' (statically typed)?


2 Answers 2


It means that Go doesn't support inheritance in the traditional object-oriented sense, preferring to focus on composition instead.

Nevertheless, you can simulate inheritance in Go, if you wish, using interfaces, structs and embedding. It would be pretty clumsy to create elaborate inheritance hierarchies this way, though.

Further Reading
Object Oriented Inheritance in Go


There are two possible answers for this. The first answer is the answer to your literal question:

What does “a type system [that] has no hierarchy” mean?

It means exactly that: there is no hierarchy. I.e. there are no sub/super relations between the types. Or, in other words: it is a type system without subtyping, just like C, Haskell, ML, Pascal, and many other languages.

Is it like python that types are been checked at run time (dynamically typed) rather than 'compile time' (statically typed)?

No. Those two things are completely unrelated. They are completely orthogonal. You said it yourself: dynamic vs. static typing refers to when the type checking takes place. It has absolutely nothing to do with whether or not types can have hierarchical relations.

Note: this has nothing to do with inheritance. Inheritance and subtyping are orthogonal. Subtyping is about relations between types. I.e. relations between specifications and restrictions. Inheritance is about relations between implementations. It basically allows you to reduce code duplication by only specifying how your code differs from some existing code.

Unfortunately, many languages such as C++, Java, C♯, etc. conflate the two concepts. In those languages, you cannot create a subtype without also inheriting its implementation, and vice versa. (If you imagine a version of Java where only interfaces are types and classes aren't, then you would have a language that separates subtyping and inheritance, for example. Note that this is actually the recommended way to program in Java, anyway!)

Now, the second possible answer takes into consideration the context of the document within which you found that particular quote. And that answer is basically, that unfortunately the authors of that particular section of the Go FAQ also seem to conflate inheritance and subtyping, and in addition, they seem to conflate object-orientation with inheritance. So, you'd be better off just ignoring that particular part of the FAQ, learn Go's type system, and decide for yourself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.