golang官方的FAQ，包含了初学者常见的一些问题和解答。整理下翻译和自己的见解。

https://golang.org/doc/faq#types

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes). Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.

既是也不是。尽管Go拥有类型和方法，也允许面向对象风格的编程，但它没有类型层级。 在Go中“接口”的概念提供了不同的方法，我们相信它易于使用且在某些方面更通用。 也有一些在其它类型中嵌入类型的方法，来提供类似（而非完全相同）的东西进行子类化。 此外，Go中的方法比C++或Java中的更通用：它们可被定义为任何种类的数据。 甚至是像普通的“未装箱”整数这样的内建类型。它们并不受结构（类）的限制。 此外，类型层级的缺失也使Go中的“对象”感觉起来比C++或Java的更轻量级。

Why is there no type inheritance?

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—an interface with one or even zero methods can express a useful concept. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

type inheritance - 类型继承

像需要程序员提前声明两个类型的关联，在Go中类型会自动满足任何接口， 以此实现其方法的子集。除了减少记账式编程外，这种方法拥有真正的优势。 类型可立刻满足一些接口，而没有传统多重继承的复杂性。 接口可以非常轻量——带一个甚至零个方法的接口能够表达一个有用的概念。 若出现了新的想法，或为了测试目的，接口其实可以在以后添加——而无需注释掉原来的类型。 由于在类型和接口之间没有明确的关系，也就无需管理或讨论类型层级。

It takes some getting used to but this implicit style of type dependency is one of the most productive things about Go.

它需要一段时间来适应，但这种隐式的类型依赖是Go中最具生产力的东西之一。

Why doesn't type T satisfy the Equal interface?

type Equaler interface {
    Equal(Equaler) bool
}

type T int
func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler

type T2 int
func (t T2) Equal(u Equaler) bool { return t == u.(T2) }  // satisfies Equaler

​````
在Go中，类型系统并不提升 Equal 的实参，那是程序员的责任

​``` go
type Opener interface {
   Open() Reader
}

func (t T3) Open() *os.File  // does not satisfy Opener

在Go中，T3 并不满足 Opener，尽管它在另一种语言中可能满足。 Go的类型系统确实为程序员做的更少， 子类型化的缺乏使关于接口满足的规则非常容易制订： 函数的名字和签名完全就是那些接口吗？Go的规则也容易高效地实现。

即接口满足的规则: 函数的名字和签名完全就是那些接口

Can I convert []T1 to []T2 if T1 and T2 have the same underlying type?

type T1 int
type T2 int
var t1 T1
var x = T2(t1) // OK
var st1 []T1
var sx = ([]T2)(st1) // NOT OK

In Go, types are closely tied to methods, in that every named type has a (possibly empty) method set. The general rule is that you can change the name of the type being converted (and thus possibly change its method set) but you can't change the name (and method set) of elements of a composite type. Go requires you to be explicit about type conversions.

在go语言中，类型跟方法紧密相连，因为每种具名类型都有一个（可能是空的）方法集。一条通用的规则：你可以转换类型（因此改变了方法集），但无法转换在混合类型里的元素。go要求显式的转换。