本文翻译自Go社区知名Gopher和博主Dave Cheney的文章《The Zen of Go》。

本文来自我在GopherCon Israel 2020上的演讲。文章很长:) 如果您希望阅读精简版，请移步到the-zen-of-go.netlify.com。

该演讲视频还未上线。如上线，我会把它更新到本文中的。

我应该如何编写出好代码？

我最近一直在思考很多事情，每当反思自己的工作成果时，眼前常会出现一行字幕：我该如何编写出好代码？ 主观上，没人愿意去编写糟糕的代码，那么问题来了：你是怎么知道你编写出好的Go代码了呢？

如果好与坏之间存在连续性，那么我们怎么知道哪些是好的部分？它的特性、属性、标志、模式和惯用法又是什么呢？

Go语言惯用法(idiomatic Go)

这让我走进Go惯用法。说某种东西是惯用的，就是说它遵循了时代的风格。如果某些东西不是惯用的，那它没有遵循流行的风格，感觉不时髦。

更重要的是，对某人说他们的代码不复合惯用法并不能解释为什么这些代码不符合惯用法。为什么会这样？像所有真相一样，答案可以在词典中找到：

idiom (noun): a group of words established by usage as having a meaning not deducible from those of the individual words.
惯用法（名词）：一组由用法确定的且其含义无法从单个单词的含义中推导出来的单词。

惯用法是共享价值观(value)的标志。Go惯用法不是您从书本中学到的东西，而是通过成为社区的一部分而获得的。

Go惯用法字样用多了，便形成了“口头禅”，这引起我的担忧：这种口头禅在许多方面它可能是具有排他性的。比如：有人说“你不能和我们坐在一起。” 但毕竟这不是我们批评某人的代码不符合惯用法时的索要表达的意思，是吧？他们只是没有做对，看起来不对，它没有遵循流行的风格而已。

我认为Go惯用法不是教如何编写好的Go代码的合适机制，因为从根本上说，它仍然告诉某人做错了(译注：这容易引起对方反感)。如果在他们最愿意接受建议的时候，我们给出让他们不感觉疏远的建议是否会更好些？

谚语(Proverbs)

摆脱有问题的惯用法，Gopher们还有哪些其他的文化手工艺品吗？也许我们可以转向Rob Pike精彩的Go 谚语。这些谚语是合适的教学工具吗？它们会告诉Go新手如何编写好的Go代码吗？

总的来说，我不这么认为。这并不是要驳斥Rob Pike的作品。只是像濑越宪作（Segoe Kensaku）的原著一样，Go谚语只是观察，而不是价值观的陈述。我们再次搬出字典：

proverb (noun): a short, well-known pithy saying, stating a general truth or piece of advice.
谚语（名词）：简短而众所周知的俗语，陈述一般的真理或一段忠告。

Go Proverbs的目的是揭示有关语言设计的更深层次的真理，但是像empty interface says nothing这样的建议对于一个来自商没有结构化类型的语言的新手来说有什么用呢？

重要的是要认识到，在一个不断发展的社区中，任何时候学习Go语言的人的数量都远超过那些声称掌握了该语言的人的数量。因此，在这种情况下，谚语可能也不是最佳的教学工具。

工程价值观

丹·卢（Dan Luu）找到了马克·卢科夫斯基（Mark Lucovsky）关于Windows团队在Windows NT-Windows 2000开发阶段时的工程文化的演讲。我之所以提到它，是因为卢科夫斯基将一种文化描述为一种评估设计和权衡取舍的常用方法。

讨论文化的方法有很多，但是就工程文化而言，Lucovsky的描述是恰当的。其中心思想是在未知的设计空间中用价值观指导决策。Windows NT团队的价值观是：可移植性，可靠性，安全性和可扩展性。粗略地说工程价值观就是在这里完成工作的方式。

Go的价值观

Go的显式价值观是什么呢？定义Go程序员解释世界方式的核心信念或哲学又是什么？他们如何发布宣传？他们怎么传授？如何执行？它们又是如何随着时间变化的？

作为新Go程序员，您将如何被灌输Go的工程价值观？或者，你是一位经验丰富的Go专家，你如何将你的价值观传播给“下一代”？就像我们知道的那样，知识传递的过程不是一个可选项。没有新的血液和新的观念，我们的社区将变得短视和枯萎。

其他语言的价值观

为了给我所要了解的场景做铺垫，我们可以先看看其他语言，我们看看它们的工程价值观。

例如，C++（包括其扩展：Rust）认为程序员不必为自己不使用的特性付费。如果程序未使用该语言的某些计算成本昂贵的特性，则不应强迫该程序承担该特性的成本。该价值观从语言扩展到其标准库，并用作判断所有用C++编写的代码设计的标准。

在Java，Ruby和Smalltalk中，一切都是对象的核心价值观驱动着围绕着消息传递，信息隐藏和多态的程序设计风格。在程序中采用过程式或函数式设计风格会被认为是错误的，或者按照Gophers的说法，是不符合惯用法的。

回到我们自己的Go社区，烙印在Go程序员心中的工程价值观是什么呢？在我们社区中的讨论是很容易引战的，因此要从第一条原则衍生出一套价值观念将是一个巨大的挑战。共识很关键，但随着讨论贡献者数量的增加，难度就成倍增加。但是，如果有人已经为我们完成了这些艰苦的工作了呢？

~~Python~~ Go之禅

几十年前，蒂姆·彼得斯（Tim Peters）坐下来写下了PEN-20（Python之禅）。Peters试图记录他认为Guido van Rossum(Python之父)在Python社区扮演的BDFL(仁慈的独裁者)角色时所应用的工程价值观。

在本文的剩余部分中，我将着眼于Python之禅，并问问大家：是否有什么可以用来揭秘Go程序员的工程价值观的？

一个好的package始于一个好名字

让我们从香辛的东西开始

“Namespaces are one honking great idea–let’s do more of those!” The Zen of Python, Item 19
“命名空间是一个很棒的主意-让我们多做些吧！” Python之禅，条款19

这是相当明确的，Python程序员应该使用命名空间，多多益善。

package就是Go语言的命名空间。我怀疑是否有人质疑将组件分组到程序包中利好设计和潜在重用。但关于这么做的正确方法的困惑肯定会有的，尤其是你拥有另一门语言10年的使用经验。

在Go中，每个程序包都应有一个目的/用途，而了解程序包目的/用途的最佳方法是通过其名字-一个名词。包的名字描述了它提供的内容。因此，这里重新解释一下Peters的话：每个Go软件包(package)都应该仅有一个单一的目的/用途。

这不是一个新主意，我已经说了一段时间了，但是为什么要这样做而不是使用将软件包用于细粒度分类的方法呢？为什么，因为变化(change)。

“Design is the art of arranging code to work today, and be changeable forever.” - Sandi Metz
“设计是安排代码以使其至今天仍然可以工作并且永远可以更改的艺术。” - 桑迪·梅斯

变化是我们所从事的游戏的名称(译注：这里的游戏指代程序开发工作)。作为程序员，我们要做的就是管理变变化。当我们做得很好时，我们称之为设计或架构。当我们做得不好时，我们称其为技术债务或遗留代码。

如果你编写的程序对于一组固定的输入可以一次性地完美地工作，那么没人会在乎代码的好坏，因为最终程序的输出才是企业和业务所关心的。

但这是不正确的。软件具有缺陷(bug)，需求变更，输入变更，并且很少有程序被编写为仅执行一次，因此您的程序会随着时间而变化。可能是您要为此承担任务，更有可能是其他人，但是必须更改该代码。有人必须维护该代码。

那么，如何使程序更改变得容易呢？无所不在的接口？使一切变得易于mock？邪恶的依赖注入(译注：作者对DI似乎很排斥，用了带有感情色彩的词汇)？好吧，也许，对于某类程序，但不是很多，这些技术将很有用。但是，对于大多数程序而言，预先设计一些灵活的方法要比工程设计更为重要。

相反，如果我们采取的立场是取代组件而不是增强组件，该怎么办？知道何时需要更换某些物品的最佳方法是什么时候该物品没有按照锡盒/罐头盒上的说明进行操作。

一个好的包始于选择一个好的名字。把你的包名字想象成电梯游说（Elevator pitch，即用极具吸引力的方式简明扼要地阐述自己的观点）， 仅用一个词就可以描述包的内容。当名字不再符合要求时，请查找替代名字。

简单性很重要

“Simple is better than complex.” - The Zen of Python, Item 3
“简单胜于复杂。” - Python之禅，条款3

PEP-20说：简单胜于复杂，我完全同意。几年前，我发布了这条推文:

大多数编程语言开始都是为了简单，但最终只是为了功能强大而努力。— Dave Cheney（@davecheney）2014年12月2日

至少在当时，我的观察是，我想不出一生中使用的哪门语言不标榜着简单。每种新语言都为其固有的简单性提供了理由和诱因。但是，当我研究时，我发现简单性并不是与Go语言同时代的许多现代语言的核心价值观。也许这只是一个便宜的镜头¹，但是可能是这些语言不是很简单，或者它们不认为自己很简单。他们不认为简单是其核心价值观。

但是什么时候简单变得过时了？为什么商业软件开发行业会忘记这个基本原则？

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare, The Emperor’s Old Clothes, 1980 Turing Award Lecture

“构建软件设计的方式有两种：一种方式是使其变得如此简单，以至于显然没有缺陷，另一种方式是使得它变得如此复杂以至于没有明显的缺陷。第一种方法要困难得多。” - CAR Hoare，皇帝的旧衣，1980年图灵奖演讲

我们知道：简单并不意味着容易。通常，使某些东西易于使用而不是易于构建需要更多的工作。

“Simplicity is prerequisite for reliability.” - Edsger W Dijkstra, EWD498, 18 June 1975
“简单性是可靠性的前提。”-  埃兹格·迪克斯特拉（Essger W Dijkstra），EWD498，1975年6月18日

我们为什么要追求简单？为什么Go程序简单很重要？简单并不意味着粗糙，它意味着可读性和可维护性。简单并不意味着“不复杂”，它意味着可靠，有共鸣且易于理解。

“Controlling complexity is the essence of computer programming.” - Brian W. Kernighan, Software Tools (1976)
“控制复杂性是计算机编程的本质。” - Brian W. Kernighan，软件工具  （1976）

Python是否遵守其简单性的说法尚有争议，但Go坚持将简单性作为核心价值观。我认为我们都可以认同，就Go而言，简单代码比聪明代码更可取。

避免包级别状态

“Explicit is better than implicit.” - The Zen of Python, Item 2
“显式胜于隐式。” - Python的禅宗，第2项

我认为彼得斯在这个地方的抱负胜于实际。Python中的许多内容并不明确；装饰器，dunder方法(译注：不知此为何物)等。毫无疑问，这些特性的功能强大，存在这些特性是有原因的。每个特性都是因某人非常关心的事情，尤其是复杂的特性。但是大量使用这些特性使读者很难预测操作的成本。

好消息是，像Go程序员一样，我们可以选择显式代码。显式可能意味着很多事情，也许您可能认为显式只是一种表达官僚主义和漫长风气的好方法，但这只是肤浅的解释。只关注页面的语法、烦恼行长和自制表达式是一种错误的说法。在我看来，更有价值的地方是与耦合和状态有关。

耦合(coupling)是衡量一件东西依赖另一件东西的数量的方法。如果两件事紧密结合，它们就会一起运动。影响其中一个事物的行为会直接反映在另一个事物中。想象一下，一列火车，每个车厢连在一起；发动机行驶到哪里，车厢就跟随到哪里。

描述耦合的另一种方法是内聚(cohesion)一词。内聚衡量两件事自然地在一起的程度。当我们进行一个内聚的争论，或者一个内聚的团队，它们的所有零件都可以自然装配在一起，就像设计的一样。

为什么耦合很重要？因为就像火车一样，当您需要更改一段代码时，与之紧密相关的所有代码都必须更改。一个再适合不过的例子：有人发布了他们的API的新版本，现在您的代码无法通过编译了。

API是不可避免的耦合源，但是存在更多隐蔽的耦合形式。显然，每个人都知道，如果API的原型发生更改，则该调用的传入和返回数据都会发生变化。就在函数原型中；我采用这些类型的值，并返回其他类型的值。但是，如果API以其他方式传递数据怎么办？如果每次调用此API的结果都是基于上次调用该API的结果，即使您没有更改参数该怎么办？

这是状态，状态管理是计算机科学中的问题。

package counter

var count int

func Increment(n int) int {
        count += n
        return count
}

假设我们有这个简单的counter包。您可以调用Increment以增加计数器，即便传入0，你也可以得到返回值。

假设您必须测试此代码，那么每次测试后如何重置计数器？假设您想并行运行这些测试，可以吗？现在，假设您要为每个程序进行不止一个计数，您可以这样做吗？

不，当然不行。显然，答案是将count变量封装为类型。

package counter

type Counter struct {
        count int
}

func (c *Counter) Increment(n int) int {
        c.count += n
        return c.count
}

现在想象一下，这个问题不局限于计数器，还包括应用程序的主要业务逻辑。您可以单独测试吗？您可以并行测试吗？您一次可以使用多个实例吗？如果回答那些问题为否，则原因是软件的包级别状态。

避免包级别状态。通过提供一种类型需要的依赖项作为该类型上的字段，而不是使用包变量，来减少耦合和怪异的行为。

为失败而计划，而不是成功而计划

“Errors should never pass silently.” - The Zen of Python, Item 10
“错误绝不能默默传递。” - Python之禅，条款10

有人说过，支持异常处理的语言遵循武士原则(Samurai principle)。要么全胜归来，要么(失败)全不回来。在基于异常的语言中，函数仅返回有效结果。如果他们没有成功，那么控制流程将采纳完全不同的路径。

未检查的异常显然是不安全的编程模型。当您不知道哪些语句可能引发异常时，如何在存在错误的情况下编写健壮的代码？Java尝试通过引入checked exception的概念来使异常更安全，据我所知，这种checked exception在另一种主流语言中没有被引入。有很多使用异常的语言，但是除了Java，所有语言都使用未经检查的各种异常(unchecked exception)。

显然，Go选择了不同的路径。Go程序员认为，健壮的程序是由处理失败情况的片段组成的，然后再处理happy path。在Go设计的空间中：服务器程序，多线程程序，处理网络输入的程序，如果要构建可靠的程序，那么处理意外数据、超时、连接失败和损坏的数据必须是程序员的首要任务。

“I think that error handling should be explicit, this should be a core value of the language.” - Peter Bourgon, GoTime #91
“我认为错误处理应该是显式的，这应该是语言的一个核心价值观。” - 彼得·布尔贡（Peter Bourgon），GoTime＃91

我想回应彼得的主张，因为这是本文的动力。我认为Go的成功很大程度上归功于显式的处理错误的方式。Go程序员首先考虑失败情况。我们首先解决如果...怎么办的情况。这导致程序在编写时处理故障，而不是在生产中处理故障。

反复出现的下面代码片段：

if err != nil {
    return err
}

所付出的成本已基本被在故障发生时刻意处理每个故障情况的价值超过了(译者注：上面的重复代码段也是利大于弊)。关键还在于显式处理每个错误的文化价值观。

早点返回，而不是深层嵌套

“Flat is better than nested.” - The Zen of Python, Item 5
“扁平比嵌套更好。” - Python的禅宗，条款5

这是一个明智的建议，而且它来自以缩进作为控制流主要形式的语言。我们如何用Go来解释这个建议呢？gofmt控制Go程序的整体风格(空白与缩进)，因此无需执行任何额外操作。

我之前写过关于package名字的文章，这里可能有一些建议：避免复杂的软件包层次结构。以我的经验，程序员越努力细分和分类Go代码库，他们越有可能陷入包导入循环的死角。

我认为第5项条款建议的最佳应用是函数内的控制流。简而言之，避免需要控制流缩进过深。

“Line of sight is a straight line along which an observer has unobstructed vision.” - May Ryer, "Code: Align the happy path to the left edge" https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

“代码行展现给观察者的视觉效果应该是一条畅通的直线。- May Ryer， “代码：将快乐路径对齐到左边缘”

Mat Ryer将这种想法描述为视线编码(line of sight coding )。视线编码意味着：

• 如果不满足前提条件，则使用保护子句尽早返回。
• 将成功的return语句放在函数的末尾，而不是放在条件代码块中。
• 通过提取函数和方法来降低函数的整体缩进级别。

该建议的关键是您所关心的事情，功能所要做的事情永远不会有在屏幕右侧滑出视线的危险。这种风格有一个额外的副作用，您可以避免团队中对行长度的毫无意义的争论。

每次缩进时，都会向程序员堆栈添加另一个先决条件，从而消耗他们的7±2个短期内存插槽之一(译注：7±2指的是人类能短期记忆的事件数量大约是7，±2是个体差异)。将函数的成功执行路径贴近屏幕左手侧，不要深入嵌套。

如果你认为它性能差，请通过基准测试证明

“In the face of ambiguity, refuse the temptation to guess.” - The Zen of Python, Item 12
“面对模棱两可，拒绝猜测的诱惑。” - Python之禅，条款12

编程基于数学和逻辑，这两个概念很少涉及机会元素。但是，作为程序员，我们每天都在猜测许多事情。这个变量有什么作用？此参数有什么作用？如果我在这类传入nil会怎样？如果我调用Register两次会怎样？实际上，现代编程中存在很多猜测，尤其是在使用不是你编写的库时。

“APIs should be easy to use and hard to misuse.”  - Josh Bloch
“API应该易于使用并且不容易被滥用。” - 乔什·布洛赫（Josh Bloch）

我知道的帮助程序员避免猜测的最好方法之一是在构建API时，应专注于默认用例。使调用者尽可能轻松地执行最常见的事情。但是，我过去写过很多关于API设计的文章，所以我对第12项的解释是：不要猜测性能。

尽管您可能考虑到Knuth的建议，但Go语言成功的推动力之一是其高性能的执行。您可以在Go中编写高性能的程序，因此人们会因此选择Go。关于性能有很多误解，所以我的要求是，当您希望对代码进行性能调优时，或者遇到一些教条式的建议时，例如defer缓慢，CGO昂贵，或者始终使用原子操作而不是互斥锁时，请不要猜。

不要因为过时的教条而使您的代码复杂化，并且，如果您认为某些事情很慢，请首先使用基准测试进行证明。Go提供了出色的基准测试和性能分析工具，这些工具均可免费获得。使用它们来找出您程序中的性能瓶颈。

在启动goroutine之前，请知道它何时会停止

在这一点上，我认为我已经从PEP-20中挖掘了有价值的要点，并且可能扩展其重新解释的范围。我认为很好，因为尽管这是一种有用的修辞手法，但最终我们还是在谈论两种不同的语言。

“You type go, a space, and then a function call. Three keystrokes, you can’t make it much shorter than that. Three keystrokes and you’ve just started a sub process.” - Rob Pike, Simplicity is Complicated, dotGo 2015

“您键入go，一个空格和一个函数调用。三次按键，您不能做到比这还短了。三次按键，您就启动了一个子过程。” - 罗伯·派克（Rob Pike），Simplicity is Complicated，dotGo，2015年

接下来的两个建议，我将专注于goroutines。Goroutines是语言的标志性功能，这是我们给出的关于一等公民(first class)并发的答案。它们非常易于使用，只需将单词go放在语句前面，即可异步启动该函数。非常简单，没有线程，没有堆栈大小，没有线程池执行程序(thread pool executor)，没有ID，没有跟踪完成状态。

Goroutines代价很低。由于运行时(runtime)能够将goroutine多路复用到一个小的线程池中（您不必管理），因此可以轻松容纳数十万，数百万个goroutine。这开创了在竞争性并发模型（例如线程或事件回调）下不可行的设计。

但是，即便如goroutine一样便宜，但它们也不是免费的。至少它们的堆栈有几千字节，当您启动10^6个goroutine时，它们的确开始累加。这并不是说就不应该使用数百万个goroutine，如果你的设计需要，可以做。但是当您这样做时，请务必对其进行跟踪，因为10^6数量级的任何东西累计可能消耗的资源都不是少量的。

Goroutines是Go中资源所有权的关键。为了程序有用，goroutine必须做一些事情，这意味着它几乎总是持有对资源的引用或所有权：锁、网络连接、带有数据的缓冲区、channel的发送端。当该goroutine处于活动状态时，将持有锁，保持网络连接打开，保留缓冲区，并且channel的接收器将继续等待更多数据。

释放这些资源的最简单方法是将它们与goroutine的生命周期相关联-当goroutine退出时，资源释放。因此，尽管开始执行goroutine几乎是微不足道的，但在进行三次按键(go+空格)前，请确保您对以下问题有答案：

• goroutine在什么情况下会停止？ Go没有办法告诉goroutine退出。没有停止或终止功能，这是有充分的理由的。如果我们无法命令goroutine停止，则必须礼貌地对其提出要求。这几乎总是归结于channel操作。当channel关闭时，针对一个channel的range loop将退出循环。如果一个channel关闭，它将变为可选(selectable)。从一个goroutine到另一个goroutine的信号最好表示为一个关闭的channel。

• 出现这种情况需要什么？ 如果channel既是在goroutines之间进行通讯的工具，又是它们传达完成信号的机制，那么程序员面临的下一个问题就是，谁将关闭channel，何时会发生？

• 您将使用什么信号知道goroutine已停止？ 当您发出信号告知goroutine要停止时，在将来的某个时间gouroutine停止动作会发生。就人类的感知而言，它可能很快发生，但是计算机每秒执行数十亿条指令，并且从每个goroutine的角度来看，它们的指令执行是不同步的。解决方案通常是使用channel发应答信号或fan-in方法需要的waitgroup。

将并发留给调用者

在您编写的任何严肃的Go程序中，都可能涉及并发。这就提出了一个问题，我们编写的许多库和代码都采用每个连接一个goroutine或采用工作者(worker)模式。您将如何管理这些goroutine的生命周期？

net/http是一个很好的例子。关闭拥有监听套接字的server相对来说是直截了当的，但是从该接受套接字产生的goroutines呢？net/http确实在请求对象中提供了一个上下文(context)对象，该上下文对象可用于向正在监听的代码发出信号，表明应该取消请求(cancel)，从而终止goroutine，但是尚不清楚如何知道何时完成所有这些操作。一种方法是调用context.Cancel，知道取消已经完成是另一回事。²

我想说明的一点net/http是，它是良好实践的反例。由于每个连接都是由net/http.Server类型内部产生的goroutine处理的，因此驻留在程序net/http包外部的程序无法控制接受套接字产生的goroutine。

这是一个仍在不断发展的设计领域，例如go-kit的run.Group和Go团队等努力ErrGroup提供了执行，取消和等待异步运行功能的框架。

这里更大的设计准则是针对库编写者的，或者是任何编写可以异步运行的代码的人，将使用goroutine的责任留给调用者。让调用者选择他们希望如何启动，跟踪和等待函数执行。

编写测试以锁定包API的行为

也许您希望从我这里读到一篇我不咆哮测试的文章。可悲的是，今天不是那天。

测试是关于您的软件做什么和不做什么的契约。程序包级别的单元测试应锁定程序包API的行为。他们用代码描述了程序包承诺要做的事情。如果针对每个输入排列组合都有一个单元测试，那么您已经定义了代码将在代码（而不是文档）中执行的约定 。

通过简单的输入go test，您就可以断言代码是否遵守契约。在任何阶段，您都可以高度自信地知道人们在更改之前所依赖的行为在更改之后将继续有效。

测试会锁定api行为。添加，修改或删除公共api的任何更改都必须包括对其测试的更改。

适度是一种美德

Go是一种简单的语言，只有25个关键字。在某些方面，这使该语言内置的功能脱颖而出。同样，这些是语言销售的功能，轻量级并发，结构化类型。

我想我们所有人都经历过尝试立即使用Go的所有功能所带来的困惑。谁对使用channel如此兴奋以至于他们尽可能多地，尽可能多地使用它们？就我个人而言，我发现结果很难测试，脆弱且最终过于复杂。只有我一个人吗？

我在goroutines上经历了相同的经历，试图将工作分解成很小的单元，我创建了一群难以管理的goroutines，最终观察到我的大多数goroutines总是阻塞等待–代码最终是顺序的，我增加了很多复杂性，几乎没有给现实世界带来任何好处。谁经历过这样的事情？

我在嵌入机制方面(embedding)也有同样的经历。最初，我将其误认为是继承。然后，我通过将已经承担多个职责的复杂类型组合成更复杂的巨大类型重现了创建脆弱的基类问题。

这可能是最不可行的建议，但我认为这一点很重要。建议始终是相同的，所有事情都要适度，Go的特性也不例外。如果可以的话，请不要寻求goroutine或channel，也不要嵌入结构，匿名函数，过渡用package，为每样东西建立接口(interface)，要用简单方法而不是聪明的方法。

可维护性很重要

我想谈谈关于PEP-20的最后一项，

“可读性很重要。” - Python之禅，条款7
“Readability Counts.” - The Zen of Python, Item 7

关于可读性的重要性已经被谈论了很多，不仅在Go语言中，而且在所有编程语言中。像我这样的人，倡导在Go的舞台上使用简单，可读性，清晰度，生产力等词，但最终它们都是一个词的同义词- 可维护性。

真正的目标是编写可维护的代码。原始作者之后的代码可以存活下了。存在的代码不仅可以作为时间点投资，而且可以作为未来价值的基础。不是可读性并不重要，而是可维护性更重要。

Go并不是为聪明人而优化的语言。Go不是一种为了在程序中编写最少行数而进行优化的语言。我们没有针对磁盘上源代码的大小进行优化，也没有针对将程序键入编辑器花费的时间进行优化。而是，我们希望优化我们的代码以使读者清晰(clear)。因为需要维护此代码的人正是读者。

如果您是为自己编写程序，则也许只需要运行一次，或者您是唯一会看到该程序的人，然后程序为您工作。但是，如果这是一个将由多个人贡献的软件，或者将由人们使用足够长的时间以致其需求，功能或运行环境可能发生变化，那么您的目标必须是针对程序的可维护性。如果无法维护软件，则它将被重写；那可能是您的公司最后一次投资Go。

你离开后，您努力实现东西可以维护吗？您今天该如何做才能使某人明天更容易维护您的代码？

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文是gohugo作者Steve Francia在意大利佛罗伦萨举办的GoLab上分享的闭幕演讲讲稿的文字版，该演讲的主题为”Go的遗产”。该演讲讨论了Go语言继承的遗产，以及它是如何尊重这些遗产的，并在最后总结了Go希望留给后来者的遗产。

演讲胶片

我们有责任保留好留给我们的遗产，并留下值得我们子孙后代继承的遗产 – 克里斯汀·格雷格（Christine Gregoire）

1. Go语言之前

1950年

在1950年代后期，人们对每台新计算机如何产生自己独特的语言而感到不安。当时，编程语言是由硬件制造商提供的，并且因型号而异。跨计算机且保持一致的第一门编程语言是Fortran，但这仍然仅适用于其制造商IBM(生产的计算机)。而后，人们成立了一个委员会，该委员会的使命就是设计第一种真正通用的、独立于机器的编程语言。

图：编程语言历史Babel塔，CACM封面，1961年1月

1960年

1960年1月，有13位计算机科学家在巴黎举行了一次空前的会议，旨在(设计)开发出这样一种语言。美国派出了6位代表，欧洲派出了7位代表。

会议上无休止、令人振奋的讨论也让科学家们筋疲力尽。当一个人的好主意与他人的坏主意一起被抛弃时，一个人就会变得更加恼火。然而，在整个会议期间内，大家都没有懈怠，持续地努力投入着。

最终这13名科学家的思想碰撞产生了良好的化学反应 – Alan Perlis。

Algol

这是一种远远超越其时代的语言，它不仅是对其前辈的一种改进，而且对其所有后继者也产生了重大影响。- Tony Hoare关于编程语言设计的提示– 1973年

• 尽管发表了这一声明，但Tony Hoare和Niklaus Wirth还是一起创建了称为ALGOL W的ALGOL 60的后继产品。
• 进而导致Niklaus Wirth继续创建了Pascal，Pascal编程语言最初于1970年发布。
• 接下来，CPL(Combined Programming Language)在剑桥大学独立创建，也被称为“剑桥编程语言”。
• 接下来，一种称为BCPL(或Basic CPL)的、基于CPL但比CPL更简单的编程语言诞生。
• 在美国贝尔实验室，Ken Thompson和Dennis Ritchie创建了B语言，主要基于BCPL。
• 在B语言发明后不久，它的后继者C语言就诞生了。

之后，原本一脉相承的语言出现了分裂：

• Pascal这一分支在欧洲蓬勃发展，有许多继任者，包括Modula和Oberon。

• C语言在美国激增，激发和促进了C++、C＃、Java以及JavaScript、Python、Perl、PHP和许多其他语言的诞生和发展。

• 到2007年，存在的数十种编程语言都可以追溯到其共同祖先：Algol。

1964年

我们的并发故事始于Doug McIlroy，他在1964年提出了一些新的想法，这些想法最终演化为Unix Pipes。

当有必要以另一种方式处理数据时，我们应该有一些耦合程序的方法，例如像将花园软管拧入另一部分那样。这也是IO的方式。- Doug McIlroy

背后故事

在1970年至1972年的一段时间内，我不时说：“如何做这样的事情？”，然后我提出了另一个建议，另一个建议，另一个建议。有一天，我想出了一种shell语法用于支持管道使用，Ken说：“我要去实现它！”他厌倦了听到所有这些内容……[并且]他说，“要去实现它”。他没有完全按照我为管道系统调用所建议的去做。他发明了一种更好一点的东西，终于又改变了今天的样子。他在一夜之间将管道符放入了Unix（并且他做到了）……。

麦克罗伊（McIlroy）引述：布赖恩（Brian）的墙上还挂着一张纸，在那张纸上我谈到了像花园软管那样将流（stream)拧在一起。所以这个想法在我脑海中徘徊了很长时间。

同时，在Thompson和Ritchie在黑板上，草拟了一个文件系统，我正在草拟如何在黑板上进行数据处理，方法是将一系列过程串联在一起，并寻找一种将过程连接在一起的前缀表示法语言。之所以失败，是因为很容易说出“cat into grep into……”或“who into cat into grep”等等。这么说很容易，而且从一开始就很清楚，这就是您想说的。但是这些命令具有所有这些附带的参数。它们不仅具有输入和输出参数，还具有选项，并且在语法上还不清楚如何将这些选项插入以前缀表示法编写的链中，比如：cat（grep（who …））。在句法上很多人不知道如何做。所以我把这些非常漂亮的程序写在黑板上，用的语言不够强大，无法应付现实。因此，我们实际上并未这样做。

1978年

到1978年，在对多处理器进行编程的背景下，有许多提议的方法被用于通信和同步。共享内存是最常见的通信机制。

托尼·霍尔（Tony Hoare）发表了一篇论文，该论文改变了一切。它比时代提前了几十年。他称他的论文为:”通讯顺序进程，communicating sequential processes”，就是大家熟知的CSP。

• 进程(Processes)：执行单元
• 顺序(Sequential)：每个进程都作为一个普通的单线程程序运行
• 通讯(Communicating)：进程如何协调
• 没有内存共享
• 没有线程，没有互斥体

Hoare的论文提出了一种语言，每个进程（或者作为一个普通的单线程程序）按顺序执行，通过无缓冲通道(unbuffered channel)相互通信。Hoare的通信进程比典型的Unix Shell管道更通用，因为它们可以以任意模式连接。

三个语言分支因Hoare的CSP论文而诞生：Erlang 、Occam和Newsqueak。

• 1983年诞生的Occam最接近CSP论文（由Hoare推荐）
• Erlang在80年代后期专注于CSP的功能方面，并使用mailbox在进程之间进行通信
• Rob Pike(Newsqueak之父)追逐了并发白鲸(the concurrency white whale)长达20年

Go是第一种可以同时拥有欧洲和美国语言设计分支传统的语言。实际上，它已经统一了这三个分支

2016年，黑客新闻评论（Hacker News）上的一则帖子称Go语言时停留在70年代的一种语言，这引起了一些对Go的批评……

2. 对过去伟大思想的复兴

编程语言发展的四波浪潮

• 第一波浪潮：语言扩张 – 巴别塔

特征：多样化。很久以前，语言是多种多样的，并在在思想、方法和意见等方面体现出多样性。

• 第二波浪潮：语言的标准化

特征：快速、复杂且对开发不友好。语言的标准化发生了数十年。到2000年代，事情开始停滞。他们融合为两个阵营：Java/JVM和C/CLR。C++、Java、C＃都非常相似。

• 第三波浪潮：脚本语言

特征：慢、不安全但对开发友好。脚本语言作为对上述语言的复杂性和痛苦的回应而应运而生。它们开发快速而松散，对开发人员友好，但缺乏性能和安全性。

• 第四波浪潮：恢复

特征：快速、安全、对开发人员友好

Go是对这些语言的复杂性和痛苦的一种反应，也是对脚本语言快速开发和松散本质的反应。

Go恢复了早期语言的简单性和灵活性，增加了现代语言的安全性和开发友好性。Go以一种非常真实的方式复兴了许多伟大的想法，这些想法终于准备就绪。

Go给人的感觉就像是来自60年代，70年代，80年代，90年代，00s，10年代的语言……Steve Francia 2019

Go感觉像这样是因为它由过去60年来的许多伟大构想组成。

现在，我想谈谈Go中的3种特定功能(简单、并发和Go的OO)以及这些思想起源的4种语言(Oberon、Newsqueak、Simula和Smalltalk)。在Go恢复它们之前，许多思想被遗忘了。

1988年

简单易读的结构和语法: Oberon＆C

Niklaus Wirth负责Algol-W，Pascal，Modula。现在是1988年，他的最新语言是Oberon。

Oberon的程序结构，以“hello, world”例子为例:

MODULE hello;

IMPORT Out;

BEGIN
    Out.String("Hello, World"); Out.Ln
END hello.

Oberon围绕着爱因斯坦（Albert Einstein）的座右铭设计：“使事情尽可能简单，但不要过于简单。”

程序结构非常简单。

下面是Go的”hello world”程序结构：

package main

import "fmt"

func main（）{
    fmt.Println"hello world"）
}

这个例子看起来应该很熟悉，它直接采用Oberon的结构。

我们再来看看Oberon的声明结构：

CONST n = 42；
TYPE mystring = ARRAY 32 OF CHAR;
VAR s: mystring;

PROCEDURE squared(x:INTEGER):INTEGER;
BEGIN
    RETURN x * x
END squared;
VAR b,c: INTEGER = 1,2;

再来看看Go的声明结构：

const n = 42

type mystring string

var s mystring

func squared(x int) int {
    return x*x
}

var b, c int = 1, 2

在Go和Oberon中，声明都是从左到右（名称，类型，可选值），这恰与C相反，在C语言中，类型放在前面。

很多人看到Go后会问为什么我们要翻转C语法，他们错误地认为Go的声明结构来自C语言。它不是，它来自Oberon。

Go使用了Oberon形态，但却用C的token：

• {}代替BEGIN END
• ++，– 代替（内置）的INC和DEC
• != 代替#
• ％代替MOD
• || 代替OR
• []代替ARRAY
• 结构体代替RECORD
• *代替POINTER TO

虽然结构来自Oberon，但Go使用的token却来自C。

• 这里没有太多，这就是重点。语法和结构都很简单。
• 没有继承，没有层次。没有复杂的作用域(scope)系统。
• 它们尽可能简单，但并不过于简单。

您可以看到Go如何采用Oberon的简单结构，但是删除了笨拙的语法，并采用C语言的更加优雅和熟悉的语法替换了它们。

这样做的结果是一种非常易读的语言诞生了。

1989年

并发与Newsqueak

罗伯·派克（Rob Pike），他于1989年在贝尔实验室工作。他在这里设计了Newsqueak。

• Newsqueak是一门用于研究和探索的编程语言
• 它致力于在Sequeak基础上添加实用的、切实可行的并发(concurrency)支持
• Newsqueak语法上类似C
• 像CSP一样，Newsqueak使用Channel作为Process的集合点

Rob Pike的Newsqueak在语法上看起来像C，但对并发支持的更好。Squeak用于设计菜单和滚动条之类的设备，Newsqueak解决了同样的问题，但涉及范围更广：Newsqueak用于编写整个应用程序，尤其是窗口系统。

Newsqueak-Prime Sieve pt.1

译注：Rob Pike拿手的素数筛例子

counter := prog(end: int, c: chan of int) {
    i: int;
    for(i = 2; i<end; i++) c<-=i;
};

filter := prog(prime: int, listen, send: chan of int) {
    i: int;
    for(;;)
        if((i=<-listen)%prime)
            send<-=i;
};

Newsqueak-Prime Sieve pt.2

sieve := prog(c: chan of int) {
    for(;;) {
        prime := <-c;
        print(prime, “ “);
        newc := mk(chan of int);
        begin filter(prime, c, newc);
        c = newc;
    }
};

count := mk(chan of int);

begin counter(10000, count);
sieve(count);

与CSP和Squeak不同，Newsqueak将channel视为一等公民：channel可以存储在变量中，可以作为参数传递给函数，甚至channel自身也可以通过channel发送。

另外”<-c(receive)”表达式也是第一次在这里介绍。

channel和routine

Go:

c := make(chan int)
c <- 1
x = <-c
go f(x)

vs.

Newsqueak:

c := mk(chan of int);
c <- = 1;
x = <-c;
begin f(x);

我们看到：Go的并发方法几乎与Newsqueak完全相同，channel和 goroutines的使用方式也是相同的。

select

Newsqueak还使用了看起来与Go的select语句非常相似的select。

select {
    case msg1 = <-c1:
        print(“received”, msg1, “\n”);
    case msg2 = <-c2:
        print(“received”, msg2, “\n”);
}

您可以清楚地看到Go并发的基础在25年前是如何在Newqueak中被建立起来的。Go采纳了这些”老想法”，并对其进行了改进，使其可以投入生产。

Ryan Dahl: Node.js的创建者的访谈(2017)

我喜欢Go的编程模型。使用goroutine是如此简单和有趣……如果您要构建服务器，那么我无法想象使用Go以外的任何工具。Goroutine使Go的并发变得简单。

1965年

面向对象基础(Smalltalk)

OO在C++/Java之前就已存在，在C++和Java重新定义面向对象之前。

什么是面向对象？

• 附加到数据对象的过程(Procedure)
• Procedure的可重用性

Procedure+数据

Simula继承了Algol，并在其中添加了对象，类，继承和子类。 Simula被认为是第一种面向对象的编程语言，并且在Smalltalk和所有随后的OO语言的开发中具有重要的影响力。

Simula改变了一直以来的从Procedure的角度来看的思维方式，…他将其翻转为…面向对象的视角，即在每种类型的对象中，您都有处理它的所有方法。- Small Talk的实现者Dan Ingalls

1980

接下来是Smalltalk，其中一切都是对象，并且仅通过发送消息与对象进行通信。

我确实发明了“面向对象”这个术语，但这是一个错误的选择，因为它没有强调消息发送这个更重要的思想。 – Alan Kay: 从A到Z的编程语言：Smalltalk-80 – 2010

1989年

Procedure重用

我们将讨论两个出版物:

如果系统的任何部分取决于另一部分的内部结构，那么复杂度会随着系统大小的平方而增加 – Dan Ingalls面向对象编程— 1989年

继承。 我们看到了继承带来的这种指数级复杂性

对于使用半新的OO语言进行编程的任何人，这应该看起来都很熟悉。关系线无处不在。 – SPAGHETTI CODE的诞生

论文《强类型面向对象编程的接口》中所提到的系统提供了Ada和Modula-2之类的语言中的模块接口的优点，同时保留了可表达性，使无类型的面向对象的语言（如Smalltalk）具有灵活性。

Go interfaces

type Point interface {
    X() int
    Y() int
    Move(int,int)
    Point Equal(Point) bool
}

Go团队在实现interface时并不知道到该论文的存在。由于这两种方法的明显相似性，后来与他们share了该论文。

Go采取了非常相似的方法，但是对上面论文中想法进行了改进，因为Go接口是隐式的，这使Go应用程序解耦并提供了极大的灵活性。

当您尝试分解一个复杂的问题时，您想要尝试将其分解为尽可能少的部分，并且希望它们尽可能独立。 – Dan Ingalls 面向对象编程— 1989

Go的interface和method采用尽可能独立的方式。只要添加正确的方法，任何类型都可以满足任何接口。可以在满足该接口的类型之前或之后定义一个接口。事实证明，这种方式是有效的，而且效果很好。

Go的OO

• method提供任何类型的消息发送机制
• 接口通过动态调度多态性提供可重用性

Go提供了像Smalltalk定义的那种面向对象编程，只是更加贴近实际，即使它不包含类，对象或继承。

• Smalltalk: OO是关于消息发送
• Go的interface允许方法像Smalltalk的消息一样自由使用，但是是在一种有类型的语言中使用

3. Go的设计哲学

2007年

在一次耗时45分钟的C++构建过程中……

罗勃·派克：把时钟拨回到2007年9月，当时我正在对一个巨大的谷歌C++程序做一些微小但重要的优化工作，你们都与这个庞大的程序做过交互。我得这个编译过程在我们的巨大的分布式编译集群上跑了约45分钟。我收到一条消息:为C++标准委员会服务的几位Google员工将进行一个演讲，他们将告诉我们C++ 11的新功能。

在一个小时的演讲中，我们听到了有关计划中的35个新功能的消息。……这时我问自己一个问题：”C++委员会真的相信C++的不足之处在于它没有足够的功能吗？” 当然……，简化语言而不是为其添加更多功能将是一个更大的成就。Rob Pike和他的办公室同事(Robert Griesemer、Ken Thompson)回到了办公桌前。这真的让他们开始思考…

现代实用的编程语言应该是什么样？到45分钟构建完成时，他们已经有了一个充满想法的白板。

语言设计的进化过程

我们从头开始构建，仅从C中借鉴了一些小东西，例如运算符和大括号，以及一些通用关键字。当然，我们还借鉴了我们所知道的其他语言的想法。- 罗伯·派克（Rob Pike)

少即是(指数级的)多 – 2012年，在谈到Go的灵感时 Rob Pike

Go的众多祖先和对Go有影响的语言：

我要说的是，没有哪位语言设计师比这三位语言设计师(Rob Pike, Robert Griesemer, Ken Thompson) 具有更广泛或更深的语言设计专业知识。他们对以前发生的事情有很丰富的了解，他们知道该采摘什么。他们还具有事后观察的优势(后发优势)。这是修复他们认为可以做得更好的事情的机会。

进化不是革命

• 原则1：大多数思想都来自先前的思想

大多数思想根本不是新事物

进化不是革命：新语言应该巩固而不是发明新特性

等待良好的设计

• 原则2：No是暂时的，Yes是永远的。

在Go的整个历史中，有很多这样的实例。通常的想法是，在设计语言时，不会出现“撤消(undo)”的情况。如果您今天说“No”，那么您明天总是可以说“Yes”，但是如果今天您说“Yes”，那么您将在很长一段时间或永远被它“困”住…。

如有疑问，请将其排除在外。- Joshua Bloch：关于设计的对话– 2002

共识驱动的设计

• 原则3: 应该使一切都尽可能简单，但不要过于简单。-爱因斯坦

当我们三个人开始时，这纯粹是研究。…我们从一个想法开始，即我们三个人都必须针对该语言的每个特性进行讨论，因此，无论出于何种原因，都不会在该语言中放入多余的垃圾。 – 肯·汤普森（Ken Thompson）访谈– 2011年，肯从Bell Labs学习了这种做法

有两种构建软件设计的方法。一种方法是使其变得如此简单，以至于显然没有缺陷。另一种方法是使其变得如此复杂，以至于没有明显的缺陷。 – 托尼·霍尔（Tony Hoare）皇帝的旧衣服-1981年，Go采取了第一种方法，而大多数其他语言都采用第二种方法。

快速迭代期待并实现大规模改变

• 最后一个原则是快速迭代的原则。

当您处于语言的设计阶段时，您将需要进行频繁且有时是巨大的更改。朝着这个期望前进，并围绕它建立您的流程。

4. 今天的Go

我们来看Go如今是如何演变的。

2019年

Go今天是如何继续进行演化的。

上面的4条原则在该语言的初期，在发行稳定版之前和被采用之前都非常有效。

但我们现在的处境非常不同。我们不再能够将所有贡献者都放在白板上，甚至不能放在如此大的房间中(译注：Go目前的contributor数量庞大)。

现在，我想与大家分享Go项目今天如何进行更改的。

我们的原则是“等待良好的设计”，这似乎意味着这是一种消极的活动，但这与事实相去甚远。真正的意思是，除非我们非常有信心采用正确的方法，否则我们不会接受更改。

这意味着所有问题的默认答案是“否”。“是”的成本非常高，因此需要一个压倒性的理由。

对一件事说“Yes”意味着对其他一切都说“No”。

软件复杂性的主要原因是供应商不加批判地采用了用户想要的几乎所有功能。人们似乎将复杂误解为先进。

不可理解的应该引起怀疑而不是钦佩。- Niklaus Wirth, 1995年

我们对Go进行了长期展望。为下一个十年或两个或更多个而设计。大多数项目的运行时间要短得多，因此通常会接受第一个可通过的解决方案。

随着时间的流逝，经过长时间这种训练的人们已经意识到：如果一个好主意会被接受，或者反之，不好的主意会被拒绝。

由于我们的长期观点，在为Go项目做出贡献时人们挣扎并不罕见。当他们的想法不能被接受时，许多人感到被亲自拒绝。

或更糟糕的是，人们会感到自己不合格或不称职。我记得有这种感觉。

几年前，我创建了一个网站引擎Hugo，随着时间的推移，它成为Go模板的第一用户，并在此过程中发现了几个问题。尽管如此，我感到非常没有资格报告这些问题，因为我认为创建这些库的“专家”显然比我了解更多，并且我无能为力。在第一次或第二次Gophercon上，我碰巧在午餐台上站在Russ Cox旁边，我们开始交谈。他强烈鼓励我报告这些问题，并让我知道他们多么地需要反馈。

几年后，我加入了Go团队，并从这个经验中学到了很多。我观察到的一件事是，Go团队那些加入较久的核心成员有一件事比大多数其他成员都做得更好，这可能不是您的想法。Go团队的老成员已经非常习惯于听到“不”的声音。我们团队成员的提议被拒绝的比率很高，甚至高于Go团队之外的提议。我们已经了解到，每个“No”都与拥有正确的“Yes”仅一步之遥。

因为我们经常听到“No”的声音，所以我们同情别人被拒绝的感觉。

今天我要传达给您的信息是您受到重视和需要。请继续尝试。在接下来的十年或二十年或更长的时间内，您是Go演化的关键部分。

Go开发流程

Go开发流程

实验流程简化始于今年早些时候，Russ Cox谈论了我们用来对Go进行更改的流程以及它的演变方式。在演讲中，他讨论了实验的两个步骤，并简化了我们的迭代过程。

我们的过程不是为了速度而建立的，而是为了正确。我们花费大量时间进行实验和简化，然后完善自己的想法，直到它们正确为止。

你们都是Go伟大实验的一部分，并且是继续构建Go的过程的关键部分

我想与大家分享3种方法，每个人都可以为Go做出贡献。

• 使用Go -> 识别问题 -> 您遇到的事情/体验并写下来。
• 您有想法-> 编写建议 -> 纳入反馈
• 您阅读提案 -> 阅读评论 > 添加您的声音

Go开发过程：实验 -> 简化 -> 最终交付。通过此提炼过程，想法将准备就绪，我们将进行交付。我想对过程的这一部分及其工作原理提供更多见解。

共识驱动的设计

• 误解：谷歌有一小群“决策者”
• 真相：评论者之间达成共识

关于提案过程的事实

• 事实上，大多提案提案都很小
• 几乎所有提案的讨论最终都在参与者（评论员）之间达成了共识。
• 提案审核委员会主要进行一些“园艺劳动”（译者：社区行为培养)

您看到这不是一件非常迷人的工作。我们评论的大多数问题都要求您澄清问题或什么也不做，让对话继续进行。我们还会考虑谁在对话中丢失，并邀请他们加入对话。

当讨论似乎已经解决（赞成或反对）时，我们将关闭其中的一小部分。

让我们看一下最近的一个建议。这只是从最近提案池中随机选取的一个。

它具有一些有趣的属性：大量参与，来自9个参与者的25条评论引用用户问题（体验）。早期该issue尚无共识（由点赞决定）。

在对该想法进行讨论和完善之后，很明显已经达成了普遍共识。

它被标记为“可能接受”，并且留下足够的时间窗口允许任何人提供我们不接受的理由。

这是一组最近审核的提案。您会注意到，他们每个人都引用了之前的评论，并根据这些评论提出了建议。

在提案审核委员会中，通常会有一个人留下评论，但代表所有出席者。Russ Cox通常志愿承担了这个角色，这就是为什么所有这些issue上面都加上他的名字的原因。在大多数情况下，此窗口不会附加注释。我们觉得这个窗口虽然很少使用，但对于建立共识的过程至关重要。

变化是缓慢发生的

这是设计使然。这是缓慢的、谨慎和有条不紊的，以确保我们最终达到想要的目标。

过去十年的主要里程碑

尽管Go的变化缓慢，但增长迅速。我想了解一下过去十年中的一些主要里程碑。

• 2009年, Go语言开源，Gopher诞生，Go脱离了Google的实验场；
• 2010年，获得年度TIOBE语言，Bossie奖，引入append和go tour；
• 2011年，gccgo合并到GCC中，引入gofix，YouTube在生产中采用了Go；
• 2012年，Go 1.0发布！发布Go1兼容性承诺；在Google内部发布第一项Go生产服务

• 2013年，Packer，Docker，Hugo用Go编写；6个月发布周期；第一个Go大会举行（日本东京）
• 2014年，Kubernetes使用Go开发；代码仓库由Mercurial→Git；第一次美国和欧洲会议；Go项目贡献者达到500名；
• 2015年，Go编译器使用Go重写，实现自举；GC精化; Women Who Go&GoBridge born; 印度、中国第一次go大会举行；
• 2016年，支持HTTP/2和Context；第一次拉丁&中东Go大会举行；最受喜欢的5门编程语言；第一次Go用户调查；贡献者达1000名；

• 2017年，GC小于ms级的暂停; 引入type alias；开发人员想要使用编程语言第一名第一次）; 13次会议; 第一届贡献者峰会
• 2018年，引入Go模块；来自Go团队之外的贡献者人数首次超过Go团队；19次Go会议；Go新品牌和logo发布；PR数在github排名第四; 开发人员打算学习的语言中排名第一

5. Go的遗产

没有时间机器可以达到未来。未来的到来缓慢而又出乎意料。我们不知道Go或世界将会发生什么。但是我们确实知道我们想留下什么标记。

• 我们希望Go能够留下创新的遗产

Go向主流受众带来了创新的想法，例如goroutine，channel，简单的interface。这些想法现在正在其他语言中出现，我们为这一趋势继续感到高兴。

Go fmt于2009年推出时颇有争议。现在，大多数语言都采用了类似的方法。

也许我们最有影响力的遗产将是，我们像Go一样激励人们挑战既定的规范，并在各处寻找灵感。

• 我们希望Go留下增强信心和能力的遗产

Go使开发人员能够编写生产服务器软件而无需C和C++所需的额外专业知识，而无需现代Java的复杂性，也无需解释语言的性能成本。

Go比其他任何语言都更能使人们把他们的想法变成现实。当我第一次开始撰写Hugo时，我个人感觉到了这一点，这是Go最吸引我的地方。

其他那些也被赋予了类似的能力和信心的人，其中许多人在本次会议上谈到了Go的创造性用途，包括Florin的家庭自动化研讨会，Ron的机器人，Elias的GUI等。

• Go改变生活。

我有幸环游世界，在任何地方遇到的男人和女人，他们通常没有CS背景或学位，但能够学习Go并用它来创办公司，获得更好的工作并改善他们和他们家人的生活。

遗产不会为人们留下任何东西。它在人们身上留下了一些东西。- 彼得·斯特普尔

我们每个人都受到过往历史的影响。我们是遗产。我们被影响，我们影响别人。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。