Go语言之父，Google大神Rob Pike代表Go语言的另外两位缔造者Robert Griesemer和Ken Thompson在自己的博客上发表了一篇名为《Go: Ten years and climbing》的文章，用以纪念Go语言从最初的设计idea起到目前的十年发展。笔者读完后，也是深有感触，因此在这里粗略翻译一下全文，希望能有更多的程序员加入到Gopher行列中来。

译文全文如下：

Drawing Copyright ©2017 Renee French

本周是创建Go语言十周年的纪念日。

记得第一次关于这门语言设计的讨论是在2007年9月20日，一个周四的下午。进而在第二天的下午两点，我、Robert Griesemer以及Ken Thompson在谷歌山景城总部43#楼的一间名为Yaounde的会议室里又组织进行了一场有关这门语言设计的会议。这门语言的名字诞生于9月25日，在第一封有关语言设计的mail中可以看到一些关于命名的设计考量：

    Subject: Re: prog lang discussion
    From: Rob 'Commander' Pike
    Date: Tue, Sep 25, 2007 at 3:12 PM
    To: Robert Griesemer, Ken Thompson

    i had a couple of thoughts on the drive home.

    1. name

    'go'. you can invent reasons for this name but it has nice properties.
    it's short, easy to type. tools: goc, gol, goa. if there's an interactive
    debugger/interpreter it could just be called 'go'. the suffix is .go
    ...

(将语言命名为Go这事儿值得一提；“golang”来自于这门语言的web站点地址（因为go.com当时已经是迪斯尼的一个web站点了），但却不是语言的恰当名字。)

Go项目将2009年11月10日，即Go项目正式开源的那天作为其官方生日。最初Go项目托管在code.google.com上，几年后迁移至GitHub。不过，现在我们要回到最初的语言概念构建阶段，即那之前的两年，这可以让我们做更进一步地回顾，以更久远的视角，见证一些语言早期的历史事件。

Go开发过程中的第一个惊喜是收到下面这封mail信息：

    Subject: A gcc frontend for Go
    From: Ian Lance Taylor
    Date: Sat, Jun 7, 2008 at 7:06 PM
    To: Robert Griesemer, Rob Pike, Ken Thompson

    One of my office-mates pointed me at http://.../go_lang.html .  It
    seems like an interesting language, and I threw together a gcc
    frontend for it.  It's missing a lot of features, of course, but it
    does compile the prime sieve code on the web page.

Ian Lance Taylor的加入以及第二个编译器实现(gccgo)在带来震惊的同时，也伴随着喜悦。这对Go项目来说不仅仅是鼓励，更是一种对可行性的证明。有了语言的第二个实现对确定语言规范和标准库的过程是至关重要的，同时也有助于Go保证其高可移植性的承诺。

虽然Ian的办公室离我们不远，但在看到这封mail之前我们从未谋面。不过，从那之后，Ian Lance Taylor便成为了Go语言及工具设计和实现的核心人物。

Russ Cox也是在2008年加入到刚成立不久的Go语言开发团队的。随着他的加入，他的一些天赋也随即在语言设计和实现中展现出来。Russ发现Go method的通用性意味着一个函数也可以拥有自己的方法，这直接导致了http.HandlerFunc的出现，这是一个我们所有人都未曾想到的结果。Russ还在当时设计的基础上提出了一些更泛化的想法，比如io.Reader和io.Writer接口，奠定了所有I/O库的整体结构。

Jini Kim是我们最初的产品经理，他招来了安全专家Adam Langley来帮助我们将Go推向Google外面的世界。Adam为我们做了许多不为外人所知的事情，包括创建最初golang.org站点的web页面以及build dashboard。不过他最大的贡献当然要属cryptographic库了。起先，对于我们中的一部分人来说，这个库无论是规模还是复杂度，和其他库比起来都不成比例。但是就是这个库在后期成为了很多重要的网络和安全软件的基础，并且成为了Go语言开发历史的关键组成部分。像Cloudflare这样的网络基础设施提供商就重度依赖Adam在Go项目中的工作，Internet也因此变得更好。因此，我们由衷感谢他的工作。

事实上，许多公司在早期使用Go进行开发，尤其是初创公司。其中一些公司成为了云计算的巨头，其中就有一家这样的公司，它现在叫Docker。这家公司使用Go语言，并催化出计算领域的容器行业，进而导致了像Kubernetes这样的项目出现。今天我们可以说Go是容器语言，这是另一个我们完全没有预料到的结果。

不过，Go语言在云计算领域起到作用更大。2015年3月，Donnie Berkholz在为RedMonk撰写的一篇文章中宣称：Go是“云计算基础设施新兴语言”。几乎与此同时，Apcera的Derek Collison说：Go已经是云计算语言了。在那个时候，这也许还不是事实。但Berkholz所使用的“新兴”一词却恰如其分的表明了Go在当时的地位。

今天，Go已经成为云计算语言。想象一下：一个只有10岁的年轻编程语言已经成为这样一个规模庞大且不断发展的行业的主导者，这样的成功以前只是存在于在想象中。如果你觉得“主导”这个词太过强势的话，让我们来看看中国互联网行业。一段时间以来，Go在中国地区大量使用的数据一度让我们误认为Google趋势图出现了某些错误，但是凡是去过中国，参加过中国区Go语言大会的人都可以证实：Google趋势图的数据是真的，Go在中国的使用非常火爆！

简而言之，Go语言的十年发展为我们带来了许多里程碑。 最令人惊讶的是我们现在的位置：保守估计表明至少有50万Go程序员。 当前面那封为Go命名的邮件发送时，憧憬能有有五十万gopher的想法听起来会感觉很荒唐。 但就在此时此刻这里，我们不仅有了50w gopher，并且数量还在持续增长。

说到gophers，很高兴看到来自Renee French想法的吉祥物Go Gopher(地鼠)，不仅成为了一个非常受人喜爱的作品，而且也是世界各地Go程序员的象征。许多各个地区顶级的Go大会都被称为GopherCons，因为他们聚集了来自世界各地的gophers。

Gopher大会正在迅速发展。第一次大会的举办只不过是三年前的事情，但今天在全世界各地有很多这样的Go大会。并且还有无数小的本地“聚会(meetups)”。在任何某一天，世界上某个地方都会有不止一个gopher群体在进行有关Go的分享。

回顾过去十年的Go设计和开发，Go社区的发展是惊人的。会议和聚会的数量、长长的且不断增加的Go项目贡献者名单、大量用Go实现的开放源代码存储库、使用Go的公司数量等等，细思恐(吃惊)极！

对于我们三个人，Robert, Rob和Ken，当初只是想让我们的编程生活更轻松一些，而如今，我们难以置信地、欣慰地看到我们的工作已经开始起作用了。

未来十年会带来什么呢？

- Rob Pike, with Robert Griesemer and Ken Thompson

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

在Go 1.3发布半年过去后，Go核心项目组于本月初发布了Go 1.4 Beta1版本。这个版本的几个变化点虽然不是革命性的，但对后续Go语言的发展来说，打下了基础，定下了基调。这里就几个值得关注的变化点结合Go 1.4代码进行一些简单描述，希望大家能对Go 1.4有个感性的认知和了解。

Go 1.4依旧保持了Go 1兼容性的承诺，你的已有代码几乎无需任何改动就可以通过Go 1.4的编译并运行。(以下是我的测试环境：go version go1.3 darwin/amd64 vs. go version go1.4beta1 linux/amd64）

一、语言变化

1、For-range循环

在Go 1.3及以前，for-range循环具有两种形式：

for k, v := range x {
    …
}

和

for k := range x {
    …
}

问题：如果我们不关心循环中的值，我们只关心循环本身，我们仍然要提供一个变量，或用_占位。

for _ = range x {
    …
}

下面这样的语法在Go 1.3及以前是无法编译通过的：

for range x {
    …
}

不过Go 1.4支持这种形式的语法，它使得代码更加clean，虽然它可能很少会被使用到。

例子：

//testforrange.go

package main

import "fmt"

func main() {
        var a [5]int = [5]int{2, 3, 4, 5, 6}
        for k, v := range a {
                fmt.Println(k, v)
        }

        for k := range a {
                fmt.Println(k)
        }

        for _ = range a {
                fmt.Println("print without care about the key and value")
        }

        for range a {
                fmt.Println("new syntax – print without care about the key and value")
        }
}

Go 1.3编译出错：

$go run testforrange.go
# command-line-arguments
./testforrange.go:19: syntax error: unexpected range, expecting {
./testforrange.go:22: syntax error: unexpected }

Go 1.4编译成功并输出正确结果：

0 2
1 3
2 4
3 5
4 6
0
1
2
3
4
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value

2、通过**T调用方法

下面这个例子：

package main

import "fmt"

type T int

func (T) M() {
        fmt.Println("Call M")
}

var x **T

func main() {
        x.M()
}

按照Go 1.4官方release note的说法，1.3版本及以前的gc和gccgo都会正常接受这种调用方式。但Go 1规范只允许自动在x前面加一个解引用，而不是两个，因此这个是有悖于定义的。Go 1.4强制禁止这种调用。

不过根据我实际的测试，Go 1.3和Go 1.4针对上面代码都会出现同样地编译错误。

$go run testdoubledeferpointer.go
# command-line-arguments
./testdoubledeferpointer.go:14: calling method M with receiver x (type **T) requires explicit dereference

二、支持的操作系统以及处理器体系架构的变化

这个无法演示。不过一个主要的变化就是Go 1.4可以构建出运行于ARM处理器Android操作系统上的二进制程序了。使用go.mobile库中的支持包，Go 1.4也可以构建出可以被Android应用加载的.so库。

三、兼容性变化

人们通过unsafe包并利用Go的内部实现细节和数据的机器表示形式来绕过Go语言类型系统的约束。Go的设计者们认为这是对Go兼容性规范的 不尊重，在Go 1.4中，Go核心组正式宣布unsafe code不再保证其兼容性。这次Go 1.4并没有针对此做任何代码变动，只是一个clarification而已。

四、实现和工具的变化

1、运行时(runtime)的变化

Go 1.3及以前版本，Go语言的runtime（垃圾收集、并发支持、interface管理、maps、slices、strings等）主要由C语言和 少量汇编语言实现的。在1.4版本中，很多代码被替换成了用Go自身实现，这样垃圾回收器可以扫描程序运行时栈，获取活跃变量的精确信息。这个变 化很大，但对程序应该没有语义上的影响。

这次重写使得垃圾回收器变得更加精确，这意味着它知道所有程序中活跃指针的位置。这些相关改变将减小heap的大小，总体上大约减少 10%~30%。

这样做的结果是栈也不再需要是分段的(segmented)了，消除了“hot split”的问题。如果一个stack到达了使用上限，Go将分配一个新的更大的stack，相应goroutine中的所有活跃的栈帧将被复制到新 stack上，所有指向栈的指针将被更新。在某些场景下，其性能将会变得显著提升，并且这样修改后，其性能更具可预测性。

连续栈(contiguous stacks)的使用使得栈的初始Size可以更小，在Go 1.4中goroutine的初始栈大小从8192字节缩小为2048字节。（正式发布时也许会改为4096）。

interface值类型的实现也做了调整。在之前的发布版中，interface值内部用一个字(word)来承载，要么是一个指针，要么是一 个单字（one-word）大小的纯量值，这取决于interface值变量中具体存储的是什么对象。这个实现会给垃圾收集器带来诸多困难，因此 在Go 1.4版本中interface值内部就用指针表示。在运行的程序中，绝大多数interface值都是指针，因此这个影响很小。不过那些在 interface值类型变量中存储整型值的程序将会有更多的内存分配。

2、gccgo的状态

Gcc和Go两个项目的发布计划不是同步的，GCC 4.9版本包含了实现了1.2规范的gccgo，下一个发布版gcc 5.0将可能包含实现了1.4规范的gccgo。

3、internal包（内部包）

Go以package为基本逻辑单元组织代码。Go 1.3及之前版本的Go语言实际上只支持两种形式Package内符号的可见性：本地的(unexported)和全局的(exported)。有些时候 我们希望一些包并非能被所有外部包所导入，但却能被其“临近”的包所导入和访问。但之前的Go语言不具备这种特性。Go 1.4引入了"internal"包的概念，导入这种internal包的规则约束如下：

如果导入代码本身不在以"internal"目录的父目录为root的目录树中，那么 不允许其导入路径(import path)中包含internal元素。

例如：
    – a/b/c/internal/d/e/f只可以被以a/b/c为根的目录树下的代码导入，不能被a/b/g下的代码导入。
    – $GOROOT/src/pkg/internal/xxx只能被标准库($GOROOT/src)中的代码所导入。（注：Go 1.4 取消了$GOROOT/src/pkg，标准库都移到$GOROOT/src下了)。
    – $GOROOT/src/pkg/net/http/internal只能被net/http和net/http/*的包所导入
    – $GOPATH/src/mypkg/internal/foo只能被$GOPATH/src/mypkg包的代码所导入

对于Go 1.4该规则首先强制应用于$GOROOT下。Go 1.5将扩展应用到$GOPATH下。

4、权威导入路径(import paths)

我们经常使用托管在公共代码托管服务中的代码，诸如github.com，这意味着包导入路径包含托管服务名，比如github.com/rsc /pdf。一些场景下为了不破坏用户代码，我们用rsc.io/pdf，屏蔽底层具体哪家托管服务，比如rso.io/pdf的背后可能是 github.com也可能是bitbucket。但这样会引入一个问题，那就是不经意间我们为一个包生成了两个合法的导入路径。如果一个程序中 使用了这两个合法路径，一旦某个路径没有被识别出有更新，或者将包迁移到另外一个不同的托管公共服务下去时，使用旧导入路径包的程序就会报错。

Go 1.4引入一个包字句的注释，用于标识这个包的权威导入路径。如果使用的导入的路径不是权威路径，go命令会拒绝编译。语法很简单：

package pdf // import "rsc.io/pdf"

如果pdf包使用了权威导入路径注释，那么那些尝试使用github.com/rsc/pdf导入路径的程序将会被go编译器拒绝编译。

这个权威导入路径检查是在编译期进行的，而不是下载阶段。

我们举个例子：

我们的包foo以前是放在github.com/bigwhite/foo下面的，后来主托管站换成了tonybai.com/foo，最新的 foo包的代码：

package foo // import "tonybai.com/foo"

import "fmt"

func Echo(a string) {
        fmt.Println("Foo:, a)
}

某个应用通过旧路径github.com/bigwhite/foo导入了该包：

//testcanonicalimportpath.go
package main

import "github.com/bigwhite/foo"

func main() {
        foo.Echo("Hello!")
}

我们编译该go文件，得到以下结果：

code in directory /home/tonybai/Test/Go/src/github.com/bigwhite/foo expects import "tonybai.com/foo"

5、go generate子命令

go 1.4中go工具集合新引入一个子命令：go generate，用于在编译前自动化生成某类代码。例如在.y上运行yacc编译器生成实现该语法的.go源文件。或是使用stringer工 具自动为常量生成String方法。这个命令并非由go tools(build, get等)自动执行，而必须显式执行。

不过我简单测试了一下，似乎这个命令设计文档中的：

// +build generate

并不好用啊。即便将其作为generate directive放入go源文件，该文件依旧会被go编译器当做正常go文件编译。Go 1.4标准库中使用go generate directive的有三个地方：

strconv/quote.go://go:generate go run makeisprint.go -output isprint.go
time/zoneinfo_windows.go://go:generate go run genzabbrs.go -output zoneinfo_abbrs_windows.go
unicode/letter.go://go:generate go run maketables.go -tables=all -output tables.go

通过go generate来实现泛型(generics)似乎不那么优雅啊。虽然设计者并非将其作为Go泛型的实现^_^。

6、源码布局变化

在Go自身源码库($GOROOT下)中，包的源码放在src/pkg中，这样做与其他库不同，包括Go自己的子库，比如go.tools。因此在Go 1.4中，pkg这一层目录树将被去除，比如fmt包的源码曾经放在src/pkg/fmt下，现在则放在src/fmt下。

五、性能

绝大多数程序使用1.4编译后的运行速度会与1.3的一致或略有提升，有些可能也会变得慢些。这次修改的较多，很难准确预测。

这次许多runtime的代码由C变为Go，这将导致一些heap大小有所缩减。另外这样做后有利于Go编译器的优化，诸如内联，会带来性能上的小幅提升。

垃圾回收器一方面得到了加速，使得重度依赖垃圾收集的程序得到可衡量的提升。但另外一方面，新的write barrier又引起了性能下降。提升和下降的量的多少取决于程序的行为。