本文永久链接 – https://tonybai.com/2024/04/22/gopher-rust-first-lesson-all-about-rust

要说这两年后端编程语言谁最火，Rust说自己第二，没人敢说第一。Rust连续8年霸榜stackoverflow最受推崇的编程语言，甚至被推特之父Jack Dorsey称为“完美的编程语言”：

注：最火：仅代表人气最旺，最受欢迎，但并不代表使用者最多。

如果你经常读我的博客，你可能会问：“你不是Go语言布道师吗？怎么也要转Rust了？”其实不然，学习Rust不是要蹭热度，而是实际开发的需要。这些年在汽车行业这个赛道上，云端和车端都要兼顾。目前车端基础软件的开发语言主要是C/C++，但内存安全、性能不输C且高可靠的Rust日益受到车载软件开发的青睐，AUTOSAR组织在2022年成立了Rust工作组就是一个重要的信号。并且据我所知，一些国内造车新势力已经或正在将一些Rust开发的中间件或应用放到了量产车或即将量产的车上。

注：AUTOSAR (Automotive Open System Architecture) 是一个面向汽车电子系统的开放式软件架构标准，由汽车制造商、零部件供应商和电子供应商共同发起并持续维护的一个全球性标准化组织。

不过，Rust语言在某些领域的崛起确实引发了其他编程语言社区的一些不满和争议。特别是Rust社区的一些人提出“Rewrite Everything in Rust”的观点，让很多编程语言社区，尤其是C++社区十分不安。Go社区则相对更加开放和友好的，主流观点是Go与Rust是可以互补的，两种语言在各自的优势领域发挥作用，通过合作而非对抗的方式，能为开发者提供更好的选择。更多细节，可以参考几年前我曾翻译过的前Go团队产品经理、gohugo的作者Steve Francia联合创作的一篇文章《Rust vs. Go：为什么强强联合会更好》。

也就是说Go依然是我的主力语言，但考虑工作上的需要，我要系统学学Rust了。为了避免“从入门到放弃”，我打算采用边学习边输出的方式，一方面可以督促自己学习，另一方面也希望能和读者及时互动，纠正学习中的错误理解。

我的Go语言第一课专栏广受欢迎，其知识结构想必也是大家认可的，这里我就仿照其形式，写一下学习Rust的第一课这个入门系列。

正如我在Go语言第一课专栏所说的那样：我一直认为，当你开始接触一门新语言的时候，你一定要去了解它的历史和现状。因为这样，你才能建立起对这门语言的整体认知，了解它未来的走向。而且，也能建立起学习的“安全感”，即相信它能够给你带来足够的价值和收益，更加坚定地学习下去。

在这篇文章中，我就先来了解一下Rust的诞生历史和现状发展，以及它独特的设计哲学。并与Go语言做个简单对比，希望能够让自己和读者对Rust有一个初步的认识。

1.1 Rust的历史与现状

1.1.1 Rust的诞生与演进

Rust诞生于2006年，这比Google三巨头“密谋”创建Go语言还要早上一年。不过和Go的三位创始人：图灵奖获得者、C语法联合发明人、Unix之父肯·汤普森（Ken Thompson），Plan 9操作系统领导者、UTF-8编码的最初设计者罗伯·派克（Rob Pike），以及Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎的设计者之一罗伯特·格瑞史莫（Robert Griesemer）相比，Rust之父格雷登·霍尔（Graydon Hoare）的身份和江湖地位却没有那么“显赫”。彼时的他只是Mozilla Research的一位加拿大籍的、不到30岁的开发人员：

注：Graydon Hoare这个人非常低调，极少在公开场合露面，因此在网络上很难找到他的肖像，上面图中的肖像来自https://www.crunchbase.com/person/graydon-hoare，我这里甚至不能保证这个肖像就是Hoare本人的。

新生代编程语言的诞生都伴随着一段轶事，比如Go语言的创始人们在Google内部经常遇到C++项目漫长的编译时间问题，每当他们启动一个C++项目的编译，都要等很长时间，期间都能喝上几杯咖啡。这让他们深有感触并意识到需要设计一门编译速度更快的新语言，于是Go语言就这样诞生了。和Go语言“喝咖啡，等C++项目编译”类似，Rust的诞生也有一段轶事：

2006年，29岁的Hoare有一天回到温哥华的家中，但他发现电梯坏了，电梯软件崩溃了！他不得不爬楼梯回到位于21层的家中。当他爬上楼梯时，他感到很恼火。他想：“我们做计算机编程的人居然无法制造出一部可以正常工作而不崩溃的电梯！” Hoare知道，许多此类崩溃都是由于程序使用内存的问题造成的。电梯等设备内部的软件通常是用C++或C语言编写的，这些语言以允许程序员编写运行速度非常快且相当紧凑的代码而闻名。问题是这些语言也很容易意外引入内存错误，这些错误会导致崩溃。Hoare决定对此做点什么。于是他打开笔记本电脑，开始设计一种新的计算机语言，他希望这种语言能够编写小而快速的代码，而不会出现内存错误，他将其命名为Rust。

这段轶事显然不可考证了。但可以确定的是从2006年开始的若干年里，Hoare创建的个人语言项目Rust并没有真正的用于改善电梯系统的程序，而是在得到了Mozilla的赞助下，用在了持续开发Mozilla的浏览器引擎Servo上了，Mozilla在2010年官宣了该项目，Hoare在2010年的一次演讲中也第一次介绍了Rust语言：

Rust开源的第一行代码也是在2010年完成的：

此外，最初的Rust编译器是由OCaml实现的，2011年Rust团队使用Rust基于LLVM重新实现了编译器并实现了自举。同年，Rust也有了自己的LOGO，其设计灵感来自于自行车齿盘：

2012年，Graydon Hoare接受InfoQ专访，谈及他带领Rust team在Mozilla开发的系统编程语言Rust，包括Rust的特性、Rust相对于C/C++/Java/Go的优势与不同以及Rust的1.0版本发布计划。

但是，就在下一年，即2013年，Graydon Hoare就因为精力耗尽而辞去了Rust team的领导职务，离开了自己的Rust team，并从此远离了Rust开发。Hoare的离开对Rust team和语言本身来说是一次重大的损失，但Rust社区和团队采取了积极的措施来确保Rust的持续发展和演进。

2014年11月，Rust官宣了cargo和crates.io，前者是Rust项目构建管理器，后者则是Rust官方维护的Rust代码的中央包存储库，通过cargo可以轻松构建和发布包到crates.io，或从crates.io上拉取Rust代码的依赖。

2015年5月15日，Rust迎来了一个里程碑的时刻：Rust 1.0正式发布！ ，这要比Go发布1.0版本迟了3年。但正如官博所说：“1.0版本的发布标志着混乱的结束。此版本是我们对稳定性承诺的正式开始，因此它为构建应用程序和库提供了坚实的基础。从现在开始，重大更改基本上超出了范围（一些小的警告适用，例如编译器错误）”。

Rust 1.0发布后，Rust的版本发布周期与节奏也得以确定下来，即每6周发布一个稳定版本，按照这个节奏，与Rust 1.0同时发布的还有Rust 1.1 Beta版本。经过六周的测试后，Rust 1.1 Beta转为Rust 1.1稳定版本，同时发布Rust 1.2 Beta版本，依次类推。当然，Rust还有一个nightly build版本，这个版本包含了最新但不稳定的特性。和Go社区和开发人员每年只能high两次相比，Rust开发者和社区更加幸运，每六周就能high一次！

Rust的演进是基于RFC（Request For Comments）驱动的，并且这一措施是早于Rust 1.0发布前就基于RFC确定下来的。这与Go的Proposal process类似，但感觉比Go的流程更规范和严谨，当然这与两种语言的治理结构的组成和规则有关。

然而，Rust 1.0的发布只是Rust语言发展的一个新起点，这件事并没有像Go语言在2009年宣布开源那样获得足够的曝光度并赢得TIOBE年度最佳编程语言的称号。

Rust之后的发展依旧是一波三折，这主要也是缘于Rust当时没有一个“好爹”：

2020年，Rust语言迎来了自己诞生以来的至暗时刻。因新冠疫情全球流行导致的业绩下滑，2020年8月，Mozilla解雇了全球1000名员工中的250名，这其中就包含Servo引擎背后的团队。该事件引起了人们对Rust未来的担忧，因为团队的一些成员是Rust的主要贡献者。

但塞翁失马焉知非福，2021年2月8日，由五家创始公司（AWS、华为、谷歌、微软和Mozilla）共同赞助的独立非营利组织Rust基金会宣布成立！Rust团队终于有了新家，并且这次除了亲爹Mozilla外，还有四个财大气粗、执IT牛耳的干爹，Rust语言的未来一下变得光明了。

实际上Rust的发展也是如此，从2021年基金会成立至今(2024.4)，Rust取得了长足的发展：语言特性不断增强，编译器性能持续优化，生态系统日渐壮大和完善，增加和完善了对WebAssembly、嵌入式、大数据、区块链、人工智能等领域的支持。下面我们就来说说Rust语言的现状。

1.1.2 Rust的现状发展

1.1.2.1 语言排名

虽然Rust热度很高，但在语言排名方面与几乎同期的Go还有一定差距，在2024.3月的TIOBE排名中，Go稳居第8位，而Rust虽然刷新了自己的历史最高排名，但也仅仅排在第17位：

在Redmonk 2024.1月排名中，Rust位列19位，Go位列12位：

不过，Rust的热度和社区活跃度甚至要高于Go，究其根源，我认为还是与两个开源语言的治理结构有关，下面是Go和Rust在Reddit论坛上的拥趸数量与在线人数对比（2024.4.6 21:39北京时间）：

如果能持续保持住这样的热度和发展势头，Rust可能在未来几年迅速接近Go的位置，甚至超越也是有很大可能的。

和Go开发人员自称Gopher类似，Rust开发人员自称Rustacean，这是一个结合了“Rust”和“Crustacean”（甲壳类）两个词语的组合词。此外，Rust社区还设计了Rust的非官方吉祥物(mascot)：Ferris，一只可爱的红色螃蟹，它是由设计师Karen Rustad Tölva在2010年创作的。Ferris象征着Rust语言的安全性、并发性和生产力，同时也代表着Rust社区的活跃和友好。

crates.io上还有一个名为ferris-says的crate，可以用来打印Ferris吉祥物相关的文字，可以输出像下面这样的ASCII字符拼接出的Ferris形象：

1.1.2.2 语言采纳

从上面TIOBE的Rust排名曲线来看，Rust在2018 edition和2021 edition前后到达过两个“尖峰”。各大公司以及初创也基本都是在2018 edition之后开始逐渐采纳Rust的。

注：关于Rust edition，感兴趣的读者可以先参考Rust官方文档，在后续学习cargo和Rust项目编译构建的时候，我们还会深入学习和理解edition。

接下来，我们列举一下Rust基金会创始公司以及其他一些知名IT公司和组织对Rust的采纳情况。

• AWS

除了成为Rust基金会创始成员，让大家真正知道了AWS对Rust投入的决心外，真正让大家看到AWS内部大量使用Rust的文章是2022年2月AWS在官博发表的一篇名为Sustainability with Rust的文章，这篇文章介绍了Rust在AWS内部基础设施构建上发挥的关键作用，包括用Rust进行Firecracker、AWS Lambda、Amazon S3、 Bottlerocket等开发。这篇文章还引用了一篇2017年发表的论文Energy Efficiency across Programming Languages中的结论，认为Rust在能耗方面的优势是其他语言如Go、Java不能匹敌的，这一定程度上引发了争议，记得Russ Cox在Twitter上海批驳了这篇文章中引用的数据不准确。

• 华为

作为国内以一己之力力抗美帝的通信、IT、手机、汽车等多赛道公司，同样也是拥有处理器、OS、编译器等全技术栈的研发型公司，华为对Rust这一的系统级编程语言尤为青睐。但从公开资料上能看到的东西不多，从华为可信编程实验室的主页上，我们看到了Rust在华为应用的一些情况。

华为的目标是在全球最大的电信行业设计值得信赖的软件系统。华为正在努力将部分代码库迁移到Rust，它比C/C++更安全且性能更高。为了帮助开发人员完成这个过程，华为利用开源C2Rust翻译器直接从C生成Rust代码。

huawei还在内部用Rust开发了一组丰富的内部库，这些库围绕基于actor的并发范式而构建，这样利用Rust语言功能（例如async、await等）简化了异步编程。

• Google

Google已将Rust应用到Chromium、Android和FuchsiaOS中，其中Chromium对Rust的支持处于实验阶段。开发者可以使用Rust来开发适用于Android和FuchsiaOS的组件，并且Rust在Android和FuchsiaOS的内部代码中使用的比例相当大，特别是FuchsiaOS，Rust代码已经超过50%。由于内部Cpp代码量较大，2022年10月，谷歌推出了基于开源RISC-V芯片的新型安全操作系统KataOS。Sparrow是KataOS的参考实现，运行在seL4上，几乎完全用Rust编写。该操作系统不是为台式电脑或智能手机设计的，而是为物联网设计的，可用于智能家居设备。目标是为嵌入式硬件或边缘设备构建可验证的安全操作系统，例如捕获图像的网络连接摄像头，这些图像在设备上或云中处理以进行机器学习。在2022年发布的Android 13版本中，谷歌还宣布Android版本13中大约21%的新原生代码（C/C++/Rust）是Rust。AOSP拥有约150万行Rust代码，涵盖了新功能和组件。此外，Android的Rust代码中已发现零内存安全漏洞。为了实现提高Android内部安全性、稳定性和质量的目标，Android团队还表示，Rust应该用在代码库中需要原生代码的任何地方。

• 微软

Microsoft拥有世界上最大的用C/C++编写的代码集合之一，其所有核心产品（例如Windows、Office和Azure云）均使用该代码。2019年，微软开始探索内存安全的编程语言，并试用了Rust。随后，Rust for Windows Library在GitHub上开源，使Rust开发人员能够顺利使用Windows API。

2022年，微软Azure CTO Mark Russinovich表示，新项目不应再使用C和C++。他建议，Rust应该用于需要非GC语言的项目，以提高安全性和可靠性。

2023年7月，微软宣布在Windows 11 Insider Preview Build 25905版本中发布了Rust参与编写的Windows内核模块。其中包含了一个 GDI 引擎的实现。

• Meta（前身为Facebook)

虽然不是创始成员，但财大气粗的Meta目前已经是唯一非创始成员的铂金赞助商了。Meta历史上以C++为主，但从2021年开始，Rust便开始大量使用Rust了，并成为Meta支持的服务器端语言列表中的最新成员。

Meta在2021和2022年先后发表过A brief history of Rust at Facebook和Programming languages endorsed for server-side use at Meta详细说明了Rust在Meta内部的应用，感兴趣的读者可以去看看。

• Linux基金会

炒得沸沸扬扬的在Linux Kernel中支持Rust语言终于尘埃落定，Linux Kernel 6.1版本对Rust提供了支持。Rust同时进入Windows、Linux内核，这让Rust的江湖地位得到进一步提升。相信未来，Rust在两大操作系统内核中的代码比例会逐步提升的。

• 其他一些公司对Rust的应用

2024年初，cloudflare公司开源了其内部替代nginx的Rust库pingora，作为业界一家提供互联网基础设施和网络服务的公司，其采用Rust的示范效应也是非常明显的。

influxdb的母公司influxdata在2023年发布了influxdb 3.0版本，该版本采用Rust全面重写。不光是influxdb，诸多新兴时序数据库都采用了Rust技术栈(+Arrow+Parquet+DataFusion)，比如greptimedb、cnosdb、CeresDB等。

字节跳动内部服务大量使用Go，但这几年也有一些Rust爱好者在字节内部布道Rust，并开源了诸如Rust RPC框架volo、基于io-uring的Rust async runtime monoio等。

埃隆马斯克的xAI在2024年发布的grok-1大模型中，Rust开发的Qdrant向量数据库也发挥了重要作用，也是Rust在AI领域应用迈出的重要一步。

1.1.2.3 应用领域

在Rust官网，我们能看到官方列出的Rust应用的四大领域：

在这四个领域中，Rust都有非常活跃的发展和应用，每个领域都有大量的优秀开源项目，这里无法穷尽，大家可以参考与awesome-go类似的awesome-rust项目查看自己关于领域的开源项目。

1.1.2.4 工作机会与薪酬

从devjobsscanner统计的2023年的各个编程语言的工作需求来看，Rust目前依旧比较小众！

从stackoverflow 2023薪酬统计来看，Rust薪资位于中游：

另外4 day week的工作数量和薪酬分析也印证了上面两点：Rust小众(工作数量相对较少)，薪酬位于中游：

国内Rust的工作数量与国际相同，都处于较少的位置，但国内Rust薪酬数据可能并不低，因为这些Rust岗位基本都在一线大厂，或是拿了较多融资的初创，待遇可能都比较不错。

了解了Rust的诞生和演化历史以及Rust的不错的现状后，我们再来看看Rust的设计哲学。

1.2 Rust的设计哲学

设计哲学之于编程语言，就好比一个人的价值观之于这个人的行为。因为如果你不认同一个人的价值观，那你其实很难与之持续交往下去，即所谓道不同不相为谋。类似的，如果你不认同一门编程语言的设计哲学，那么大概率你在后续的语言学习中，就会遇到上面提到的这些问题，而且可能会让你失去继续学习的精神动力。因此，在真正开始学习Rust语法和编码之前，我们还需要先来了解一下Rust的设计哲学，等了解完这些之后，你就能更深刻地认识到自己学习Rust的原因了。

1.2.1 Rust核心价值观

2019年6月，Rust核心组成员Stephen Klabnik在QCon London发表了一次名为How Rust Views Tradeoffs的演讲，在这次演讲中，他阐述了他个人理解的Rust的核心价值观，这些价值观是Rust team在做设计取舍时拒绝妥协的点，它们包括内存安全、执行速度和生产力：

按照Stephen Klabnik的说法，这三个核心价值观也是有序的，首先是内存安全，这是Rust最为在乎的立身之本，其次是高性能，最后是生产力。当它们之间出现冲突时，按最高价值观决策！

这其实与Rust官方对Rust的介绍也是一样的：

官方的Reliable对应的就是内存安全（memory safety)，而efficient则有两层含义，一是运行时的高效，另外一个方面则是构建时的生产力也要保持高水准。

这三个价值观是Rust语言的设计目标，也是Rust语言的特色和优势所在。在失去了Graydon Hoare这个语言之父后，这些价值观也成为了Rust核心团队在判定语言演进方向的根本依据。

1. 内存安全

内存安全是Rust最重要的价值观，它意味着Rust程序在运行时不会出现内存泄漏(不使用unsafe代码的前提下)、缓冲区溢出、野指针等内存相关的错误。这些错误不仅会导致程序崩溃，还可能导致安全漏洞的产生。Rust通过所有权（ownership）、生命周期（lifetime）和借用（borrowing）等特性，在编译时最大程度地检查出这些错误，从而保证程序的内存安全。

Rust的内存安全机制不仅能够提高程序的稳定性和可靠性，还能够降低开发和维护的难度。由于Rust能够在编译时就检查出内存错误，开发者就不必再花费大量时间和精力去寻找和修复这些错误了。

1. 高性能

高性能是Rust的仅次于内存安全的一个核心价值观，Rust语言的设计目标之一就是要成为一种高性能的系统编程语言。Rust通过零成本抽象、移动语义、泛型编程等特性，使得程序能够在运行时达到与C、C++等传统系统编程语言相当的性能。

Rust的高性能机制不仅能够提高程序的运行速度，还能够降低硬件成本。由于Rust能够更好地利用硬件资源，因此在相同的硬件条件和资源开销下，Rust程序的性能通常比其他语言的程序更高。

1. 生产力

生产力是Rust的第三个核心价值观，Rust语言的设计目标之一就是要成为一种能够提高开发者生产力的语言。Rust通过包管理器Cargo、智能编辑器支持、丰富的库生态、详实系统的文档等特性，使得开发者能够更轻松地编写、调试和维护Rust程序。

1.2.2 Rust的次要价值观

Stephen Klabnik还总结了三条Rust的次要价值观(secondary values)：

我们看到：Rust的次要价值观包括ergonomics、compile times和correctness，这三个价值观也是Rust语言的设计目标之一，但和上面的第一级核心价值观相比，它们是可以被妥协掉的。

Ergonomics是指Rust语言的易用性，它是Rust语言的一个重要设计目标。Rust希望通过简单易用的语法和丰富的库生态，使得开发者能够更轻松地编写Rust程序。

Compile Times是指Rust编译器的编译时间。Rust编译器很慢，这是一个问题，Rust team也正在努力优化，但Rust team更关心二进制文件的最终执行速度，而不是让编译器变得更快，这就是Compile Time作为次要价值观的原因。

Correctness是指Rust语言的正确性，Rust真的很在乎你的程序是否正确，Rust希望通过强大的类型系统和静态检查，来尽可能地保证Rust程序的正确性。但Rust不愿意使用完全依赖类型以及证明助手来证明你的代码是正确的。

1.2.3 与Go的价值观的对比

我们来对比一下Go官方的对Go的介绍，看一下其隐含的Go价值观(设计哲学)：

在官方对Go的介绍中有三个关键词：Simple、Secure和Scalable。

Simple是Go语言的首要设计原则，Go语言的设计者希望Go语言能够简单易用，使得开发者能够更快地学习和使用Go语言，以快速形成生产能力。Go语言的语法简单易懂，并且去掉了许多其他编程语言中复杂的特性，如类型层次与继承等，使得Go语言更加简洁易学、易读、易用和易维护。

至于Secure，Go语言的设计者希望Go语言能够更加安全可靠，避免许多其他编程语言中常见的安全漏洞。Go语言通过垃圾回收机制来自动管理内存，避免了许多其他编程语言中常见的内存泄漏和缓冲区溢出等问题。同时，Go语言提供了轻量级的goroutine和通道机制，使得开发者能够更加方便地实现并发编程，并且通过数据竞争检测工具，避免了并发编程中常见的数据竞争问题。同时Go语言提供了简单易用的显式错误处理机制，让开发者不遗漏任一处错误处理。

Scalable则体现在Go面向工程、原生内置并发以及崇尚组合的设计哲学上了。 Go语言的设计者希望Go语言能够更好地支持可扩展性，使得Go程序能够更好地适应不同的组织规模、不同的工作负载和硬件环境。Go语言通过简单的语法、基于module的可重现的构建管理、极高的编译速度、高质量的标准库、实用的工具链、强大的内置并发机制以及面向接口编程等特性，使得Go程序更加可扩展，生产力更为高效。

总的来说，Rust更注重安全、底层控制和极致性能，而Go则更加关注简单、安全、扩展性与工程效率。两者在定位和设计哲学上存在区别，但也有一些共同特点，比如都拥有现代的工具链、活跃的社区等。

1.3 本章小结

在这篇博文中，我们了解了Rust语言的诞生历程、现状发展，以及它独特的设计哲学。通过与Go语言进行对比，我们可以看出两者在出身、目标和设计理念上的一些差异。

随着软件系统的复杂度不断提高，对安全性、性能和并发的需求也越来越高。作为一门专注于底层系统编程、性能极致化的新语言，Rust正在吸引越来越多开发者的关注。相信通过后面对Rust的全方面的系统学习，我和大家都能够更深入地理解和掌握Rust。

如果你认为Rust的价值观与你的十分匹配，你也认同Rust未来的发展。那就期待下一篇吧，在下一篇中，我们将开始动手学习Rust了!

1.4 参考资料

• Rust维基百科 – https://en.wikipedia.org/wiki/Rust_(programming_language)
• How Rust went from a side project to the world’s most-loved programming language – https://www.technologyreview.com/2023/02/14/1067869/rust-worlds-fastest-growing-programming-language/
• 2022 Review | The adoption of Rust in Business – https://rustmagazine.org/issue-1/2022-review-the-adoption-of-rust-in-business/
• How Rust Views Tradeoffs – https://www.infoq.com/presentations/rust-tradeoffs/
• 非官方Rust吉祥物Ferris – https://rustacean.net

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

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

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

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

本文永久链接 – https://tonybai.com/2024/01/07/what-we-got-right-what-we-got-wrong

在《2023年Go语言盘点：稳中求新，稳中求变》和《Go测试的20个实用建议》两篇文章中，我都提到过已经退居二线的Go语言之父Rob Pike在Go开源14周年的那天亲自在GopherCon Australia 2023上发表了“What We Got Right, What We Got Wrong”的主题演讲来回顾Go诞生以来的得与失。近期Rob Pike终于将这次演进的文字稿发布了出来！GopherCon Australia也在油管上发布了这个演进的视频。Rob Pike的观点对所有Gopher都是极具参考价值的，因此在这篇博文中，我将Rob Pike的这次演讲稿翻译成中文，供大家参考(结合文字稿和视频)，我们一起来领略和学习大师的观点。

这是2023年11月10日我在悉尼GopherConAU 2023会议上的闭幕演讲（视频），那一天也是Go开源14周年的日子。本文中穿插着演示文稿中使用的幻灯片。

介绍

大家好！

首先，我要感谢Katie和Chewy让我有幸为此次GopherConAU大会做闭幕演讲。

今天是2023年11月10日，Go作为开源项目推出14周年的纪念日。

2009年11月10日那天，加州时间下午3点（如果没记错的话），Ken Thompson、Robert Griesemer、Russ Cox、Ian Taylor、Adam Langley、Jini Kim和我满怀期待地看着网站上线。之后，全世界都知道我们在做什么了。

14年后的今天，有很多事情值得回顾。我想借此机会谈谈自那一天以来学到的一些重要经验。即使是最成功的项目，在反思之后，也会发现一些事情本可以做得更好。当然，也有一些事情事后看来似乎是成功的关键所在。

首先，我必须明确的是，这里的观点只代表我个人，不代表Go团队和Google。无论是过去还是现在，Go都是由一支专注的团队和庞大的社区付出巨大努力的结果。所以，如果你同意我的任何说法，请感谢他们。如果你不同意，请责怪我，但请保留你的意见。

鉴于本次演讲的题目，许多人可能期待我会分析语言中的优点和缺点。当然，我会做一些分析，但还会有更多内容，原因有几个。

首先，编程语言的好坏很大程度上取决于观点而不是事实，尽管许多人对Go或任何其他语言的最微不足道的功能都存在争论。

另外，关于换行符的位置、nil的工作方式、导出的大小写表示法、垃圾回收、错误处理等话题已经有了大量的讨论。这些话题肯定有值得讨论的地方，但几乎没什么是还没有被讨论过的。

但我要讨论的不仅仅是语言本身的真正原因是，语言并不是整个项目的全部。我们最初的目标不是创造一种新的编程语言，而是创造一种更好的编写软件的方式。我们对所使用的语言有意见——无论使用什么语言，每个人都是如此——但是我们遇到的基本问题与这些语言的特性没有太大关系，而是与在谷歌使用这些语言构建软件的过程有关。

新语言的创建提供了探索其他想法的新路径，但这只是一个推动因素，而不是真正的重点。如果当时我正在工作的二进制文件不需要45分钟来构建
，Go语言就不会出现。但那45分钟不是因为编译器慢(因为它不慢)，也不是因为它所用的语言不好(因为它也不差)。缓慢是由其他因素造成的。

我们想解决的就是这些因素：构建现代服务器软件的复杂性：控制依赖性、与人员不断变化的大型团队一起编程、可维护性、高效测试、多核CPU和网络的有效利用等等。

简而言之，Go不仅仅是一种编程语言。当然，它是一种编程语言，这是它的定义。但它的目的是帮助提供一种更好的方式来开发高质量的软件，至少与14多年前的我们的环境相比。

时至今日，这仍然是它的宗旨。Go是一个使构建生产软件更容易、更高效的项目。

几周前，当我开始准备这次演讲时，我只有一个题目，除此之外别无其他。为了激发我的思路，我在Mastodon上向人们征求意见。不少人给予了回复。我注意到了一种趋势：人们认为我们做错的事情都在语言本身，而我们做对的事情都在语言周边，比如gofmt、部署和测试等。事实上，我觉得这令人鼓舞。我们试图做的事情似乎已经产生了效果。

但值得承认的是，我们在早期并没有明确真正的目标。我们可能觉得这些目标是不言自明的。为了弥补这一缺陷，我在2013年的SPLASH会议上发表了一场题为《谷歌的Go语言：面向软件工程的语言设计》的演讲。

那场演讲和相关的博客文章可能是对Go语言为何而生的最好诠释。

今天的演讲是SPLASH演讲的后续，回顾了我们在构建语言之后所学到的经验教训，并且可以更广泛地应用于更大的图景。

那么……来谈谈一些教训。

首先，当然，我们有：

The Gopher

以Go Gopher吉祥物开始可能看起来是一个奇怪的起点，但Go gopher是Go成功的最早因素之一。在发布Go之前，我们就知道我们想要一个吉祥物来装饰周边商品——每个项目都需要周边商品——Renee French主动提出为我们制作一个这样的吉祥物。在这一点上，我们做得非常正确。

下面最早的Gopher毛绒玩具的图片：

这是Gopher的照片，它的第一个原型不太成功。

Gopher是一个吉祥物，它也是荣誉徽章，甚至是世界各地Go程序员的身份标志。此时此刻，你正在参加一个名为GopherCon的会议，这是众多GopherCon会议中的一个。拥有一个从第一天就准备好分享信息的容易识别、有趣的生物，对Go的成长至关重要。它天真又聪明——它可以构建任何东西!

它为社区参与该项目奠定了基调，这是卓越的技术与真正的乐趣相结合的基调。最重要的是，Gopher是社区的一面旗帜，一面团结起来的旗帜，尤其是在早期，当Go还是编程界的新贵时。

这是几年前Gopher参加巴黎会议的照片，看看他们多兴奋！

尽管如此，在知识共享署名许可(Creative Commons Attribution license)下发布Gopher的设计也许不是最好的选择。一方面，它鼓励人们以有趣的方式重新组合他，这反过来又有助于培养社区精神。

Renee创建了一个“模型表”来帮助艺术家在保持其精神原貌的同时进行艺术创作。

一些艺术家利用这些特征制作了自己版本的Gopher并获得了乐趣；Renee和我最喜欢的版本是日本设计师@tottie的和游戏程序员@tenntennen的：

但许可证的“归属”部分常常会导致令人沮丧的争论，或者导致Renee的创作不属于她，也不符合原作的精神。而且，说实话，这种归属往往只是不情愿地得到尊重，或者根本没有得到尊重。例如，我怀疑@tenntennen是否因他的Gopher插图被使用而获得补偿或是得到承认。

因此，如果让我们重来一次，我们会认真思考确保吉祥物忠于其理想的最佳方法。维护吉祥物是一件很难的事，而且解决方案仍然难以捉摸。

但更多的是技术性的事情。

做的对的事情

这里有一份我认为我们在客观上做对了的事情的清单，特别是在回顾的时候。并不是每一个编程语言项目都做了这些事情，但清单中的每一件对Go的最终成功都至关重要。我会试着言简意赅，因为这些话题都已为人所熟知。

1. 语言规范(Specification)

我们从正式的语言规范开始。这不仅可以在编写编译器时锁定行为，还可以使多个编译器实现共存并就该行为达成一致。编译器本身并不是一个规范。你测试编译器的依据是什么？

哦，顺便说一句，该规范的初稿是在这里编写的，位于悉尼达令港一栋建筑的18层。我们正在Go的家乡庆祝Go的生日。

2. 多种实现

Go有多个编译器实现，它们都实现相同的语言规范。有了规范就可以更容易地实现这一点。

有一天，伊恩·泰勒（Ian Taylor）发邮件通知我们，在阅读了我们的语言规范草案后，他自己编写了一个编译器，这让我们感到惊讶！

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.

这的确令人兴奋，但更多的编译器实现也随之而来了，所有这些都因正式规范的存在而成为可能。

拥有多个编译器帮助我们改进了语言并完善了规范，并为那些不太喜欢我们类似Plan-9的业务方式的其他人提供了替代环境。稍后会详细介绍。如今有很多兼容的实现，这很棒！

3. 可移植性

我们使Go应用的交叉编译变得轻而易举，程序员可以在他们喜欢的任何平台上工作，并交付到任何需要的平台。使用Go可能比使用任何其他语言更容易达成这一点。很容易将编译器视为运行它的机器的本地编译器，但没有理由这么认为。打破这个假设具有重要意义，这对许多开发者来说都是新鲜事。

4. 兼容性

我们努力使语言达到1.0版本的标准，然后通过兼容性保证将其固定下来，这对Go的采用产生了非常明显的影响！我不理解为什么大多数其他项目一直在抵制这样做。是的，保持强大兼容性的确需要付出成本，但它可以阻止功能特性停滞，而在这个几乎没有其他东西保持稳定的世界里，不必担心新版本的Go会破坏你的项目，这足以令人感到欣喜！

5. 标准库

尽管它的增长在某种程度上是偶然的，因为在一开始没有其他地方可以安装Go代码，但拥有一个坚实、制作精良的标准库，其中包含编写21世纪服务器代码所需的大部分内容，这是一个重大资产。在我们积累了足够的经验来理解还应该提供什么之前，它使整个社区都使用相同的工具包。这非常有效，并有助于防止出现不同版本的库，从而帮助统一社区。

6. 工具

我们确保该语言易于解析，从而支持工具构建。起初我们认为Go需要一个IDE，但易于构建工具意味着，随着时间的推移，IDE将会出现在Go上。他们和gopls一起做到了，而且他们非常棒。

我们还为编译器提供了一套辅助工具，例如自动化测试、覆盖率和代码审查(code vetting)。当然还有go命令，它集成了整个构建过程，也是许多项目构建和维护其Go代码所需的一切。

此外，Go获得了快速构建的声誉，这也没有什么坏处。

7. Gofmt

我将gofmt作为一个单独的项目从工具中拿出来，因为它是一个不仅在Go上而且在整个编程社区上留下了印记的工具。在Robert编写gofmt之前（顺便说一句，他从一开始就坚持这样做），自动格式化程序的质量不高，因此大多未被使用。

gofmt的成功表明了代码自动格式化可以做得很好，今天几乎每种值得使用的编程语言都有一个标准格式化程序。我们不再为空格和换行符争论，这节省了大量时间了，这也让那些花在定义标准格式和编写这段相当困难的代码实现格式自动化上的时间显得超值。

此外，gofmt还使无数其他工具成为可能，例如简化器、分析器甚至是代码覆盖率工具。因为gofmt的内容成为了任何人都可以使用的库，所以你可以解析程序、编辑AST，然后打印完美的字节输出，供人类和机器使用。

谢谢，罗伯特。

不过，恭喜你就够了。接下来，我们来谈谈一些更有争议的话题。

并发性

并发有争议吗？嗯，在我2002年加入谷歌的那年肯定有。John Ousterhout曾说过：线程很糟糕。许多人都同意他的观点，因为线程似乎非常难以使用。

谷歌的软件几乎总是避免使用它们，可以说是彻底禁止使用，而制定这一禁令的工程师引用了Ousterhout的言论。这让我很困扰。自20世纪70年代以来，我一直在做类似的并发事情，有时候甚至没有意识到，在我看来这很强大。但经过反思，很明显Ousterhout犯了两个错误。首先，他的结论超出了他有兴趣使用线程的领域，其次，他主要是在抱怨使用笨拙的低级包如pthread之类的线程，而不是抱怨这一基本思想。

像这样混淆解决方案和问题是世界各地工程师常犯的错误。有时，提出的解决方案比它解决的问题更难，并且很难看到有更简单的路径。但我离题了。

根据经验，我知道有更好的方法来使用线程，或者无论我们选择怎么称呼它们，我甚至在Go语言出现之前就曾就此发表过演讲。

但我并不孤单，其他许多语言、论文甚至书籍都表明，并发编程可以做得很好，不仅我知道这一点。它只是还没有在主流中流行起来，Go的诞生部分地就是为了解决这个问题。在那次臭名昭著的45分钟构建中，我试图向一个非线程二进制文件添加一个线程，这非常困难，因为我们使用了错误的工具。

回顾过去，我认为可以公平地说，Go在让编程界相信并发是一种强大工具方面发挥了重要作用，特别是在多核网络世界中，它可以比pthread做得更好。如今，大多数主流语言都对并发提供了很好地支持。

另外，Go的并发版本在导致它出现的语言线中有些新颖，因为它使goroutine变得平淡无奇。没有协程，没有任务，没有线程，没有名称，只有goroutine。我们发明了“goroutine”这个词，因为没有适合的现有术语。时至今日，我仍然希望Unix的拼写命令可以学会它。

顺便说一句，因为我经常被问到，让我花一分钟时间谈谈async/await。看到async/await模型及其相关风格成为许多语言选择支持并发的方式，我有点难过，但它肯定是对pthreads的巨大改进。

与goroutine、channel和select相比，async/await对语言实现者来说更容易也更小，可以更容易地内建或后移植到现有平台中。但它将一些复杂性推回给了程序员，通常会导致Bob Nystrom所著名的“彩色函数”。

我认为Go表明了CSP这种不同但更古老的模型可以完美地嵌入到过程化语言中，没有这种复杂性。我甚至看到它几次作为库实现。但它的实现，如果做得好，需要显著的运行时复杂性，我可以理解为什么一些人更倾向于不在他们的系统中内置它。不管你提供什么并发模型，重要的是只提供一次，因为一个环境提供多个并发实现可能会很麻烦。Go当然通过把它放在语言中而不是库中解决了这个问题。

关于这些问题可能要讲整场演讲，但目前就这些吧。

并发的另一个价值在于，它使Go看起来像是全新的东西。如我所说，一些其他语言在之前已经支持了它，但它们从未进入主流，而Go对并发的支持是吸引初学者采用的一个主要因素，它吸引了以前没有使用过并发但对其可能性感兴趣的程序员。

这就是我们犯下两个大错误的地方。

首先，并发很有趣，我们很高兴拥有它，但我们设想的使用案例大多是服务器相关的，意在在net/http等关键库中完成，而不是在每个程序的所有地方完成。当许多程序员使用它时，他们努力研究它如何真正帮助他们。我们应该一开始就解释清楚，语言中的并发支持真正带到桌面的是更简单的服务器软件。这个问题空间对许多人很重要，但并非所有尝试Go的人都是如此，这点指导不足是我们的责任。

相关的第二点是，我们用了太长时间来澄清并行和并发之间的区别——支持在多核机器上并行执行多个计算，以及一种组织代码的方式，以便很好地执行并行计算。

无数程序员试图通过使用goroutine来并行化他们的代码以使其更快，但经常对结果中的速度降低感到困惑。仅当基础问题本质上是并行的时候，例如服务HTTP请求，并发代码才会通过并行化而变快。我们在解释这一点上做得很糟糕，结果让许多程序员感到困惑，可能还赶走了一些人。

为了解决这个问题，我在2012年Waza上给Heroku的开发者大会做了一个题为“并发不是并行”的演讲。这是一次很有趣的演讲，但它应该更早发生。

对此表示歉意。但好处仍然存在：Go帮助普及了并发性作为构建服务器软件的一种方式。

接口

很明显，接口与并发都是Go中与众不同的思想。它们是Go对面向对象设计的答案，采用最初关注行为的风格，尽管新来者一直在努力使结构体承担这一角色。

使接口动态化，无需提前宣布哪些类型实现了它们，这困扰了一些早期评论者，并且仍然恼火一小部分人，但它对Go培育的编程风格很重要。大部分标准库都是建立在它们的基础之上的，而更广泛的主题如测试和管理依赖也高度依赖于它们慷慨的“欢迎所有人”的天性。

我觉得接口是Go中设计最好的部分之一。

除了一些早期关于接口定义中是否应该包括数据的讨论之外，它们在讨论的第一天就已经成形。

在这个问题上还有一个故事要讲。

在Robert和我的办公室里那著名的第一天，我们讨论了关于多态性应该怎么处理的问题。Ken和我从C语言中知道qsort可以作为一个困难的测试用例，所以我们三个人开始讨论用我们这种初具雏形的语言如何实现一个类型安全的排序例程(routine)。

Robert和我几乎同时产生了同样的想法：在类型上使用方法来提供排序所需的操作。这个概念很快发展成了一个想法，即值类型拥有作为方法定义的行为，一组方法可以提供函数可以操作的接口。Go的接口几乎立即就出现了。

有一点没人经常提到：Go的sort函数是作为一个在接口上操作的函数实现的。这与大多数人熟悉的面向对象编程风格不同，但这是一个非常强大的想法。

这个想法对我们来说非常激动人心，它可能成为一个基础的编程构造，这令我们陶醉。当Russ Cox加入时，他很快指出了I/O如何完美地融入这个想法，标准库的发展非常迅速，在很大程度上依赖于三个著名的接口：空接口(interface{})、Writer和Reader，每个接口平均包含两个第三个方法。那些微小的方法对Go来说是惯用法，无处不在。

接口的工作方式不仅成为Go的一个显著特性，它们也成为我们思考库、泛型和组合的方式。这是让人兴奋的事情。

但我们在这个问题上停止讨论可能是一个错误。

你看，我们之所以走上这条路，至少在一定程度上是因为我们看到泛型编程太容易鼓励一种倾向于在算法之前首先关注类型的思考方式。过早抽象而不是有机设计。容器而不是函数。

我们在语言中正确定义了通用容器——map，切片，数组，channel——而不给程序员访问它们所包含的泛型。这可以说是一个错误。我们相信，我认为仍然正确的是，大多数简单的编程任务可以很好地由这些类型来处理。但有一些不能，语言提供的和用户可以控制的之间的障碍肯定困扰了一些人。

简而言之，尽管我不会改变接口的任何工作方式，但它们以需要十多年时间才能纠正的方式影响了我们的思维。Ian Taylor从一开始就推动我们面对这个问题，但在接口作为Go编程基石的情况下，这是相当困难的。

评论者经常抱怨我们应该使用泛型，因为它们“很简单”，在某些语言中可能确实如此，但接口的存在意味着任何新的多态形式都必须考虑到它们。找到一种可以与语言的其余部分很好地协同工作的前进方法需要多次尝试，几次中止的实现，以及许多小时、天数和周数的讨论。最终，在Phil Wadler的带领下，我们召集了一些类型理论家来提供帮助。即使在语言中有了可靠的泛型模型，作为方法集存在的接口也仍然存在一些遗留问题。

如你所知，最终的答案是设计一个可以吸收更多多态形式的接口泛化，从“方法集合”过渡到“类型集合”。这是一个微妙但深刻的举措，大多数社区似乎都可以接受，尽管我怀疑抱怨声永远不会停止。

有时候要花很多年的时间来弄清楚一些事情，或者甚至弄清楚你并不能完全弄明白它。但你还是要继续前进。

顺便说一句，我希望我们有一个比“泛型”更好的术语，它起源于表示一种不同的数据结构中心多态风格。“参数多态”是Go提供的该功能的正确术语，这是一个准确的术语，但它难听。于是我们依然说“泛型”，尽管它不太恰当。

编译器

困扰编程语言社区的一件事是，早期的Go编译器是用C语言编写的。在他们看来，正确的方式是使用LLVM或类似的工具包，或者用Go语言本身编写编译器，这称为自举。我们没有做这两者中的任何一种，原因有几个。

首先，自举一种新语言要求至少其编译器的第一步必须用现有语言完成。对我们来说，C语言是显而易见的选择，因为Ken已经编写了C编译器，并且其内部结构可以很好地作为Go编译器的基础。此外，用自己的语言编写编译器，同时开发该语言，往往会产生一种适合编写编译器的语言，但这不是我们想要的语言。

早期的编译器工作良好，它可以很好地引导语言。但从某种意义上说，它有点奇怪，实际上它是一个Plan 9风格的编译器，使用旧的编译器编写思想，而不是新的思想，如静态单一赋值(SSA)。生成的代码平庸，内部不太漂亮。但它是务实高效的，编译器代码本身体积适中，对我们来说也很熟悉，这使得我们在尝试新想法时可以快速进行更改。一个关键步骤是添加自动增长的分段堆栈。这很容易添加到我们的编译器中，但是如果我们使用像LLVM这样的工具包，考虑到ABI和垃圾收集器支持所需的更改，将这种更改集成到完整的编译器套件中是不可行的。

另一个工作良好的区域是交叉编译，这直接来自原始Plan 9编译器套件的工作方式。

按照我们的方式行事，无论多么非正统，都有助于我们快速前进。有些人对这一选择感到冒犯，但这对当时的我们来说是正确的选择。

对于Go 1.5版本，Russ Cox编写了一个工具，可以半自动将编译器从C转换为Go。到那时，语言已经完成，编译器导向的语言设计的担忧也就无关紧要了。有一些关于这个过程的在线演讲值得一看。我在2016年的GopherCon上做了一个关于汇编器的演讲，这在我毕生追求可移植性的过程中是一个高点。

我们从C开始做了正确的事情，但最终将编译器翻译为Go，使我们能够将Go所具有的所有优势带到其开发中，包括测试、工具、自动重写、性能分析等。当前的编译器比原始编译器干净得多，并且可以生成更好的代码。但是，当然，这就是自举的工作原理。

请记住，我们的目标不仅仅是一种语言，而是更多。

我们不寻常的做法绝不是对LLVM或语言社区中任何人的侮辱。我们只是使用了最适合我们任务的工具。当然，今天有一个LLVM托管的Go编译器，以及许多其他应该有的编译器。

项目管理

我们从一开始就知道，要成功，Go必须是一个开源项目。但我们也知道，在弄清楚关键的思想和有一个工作的实现之前，私下开发会更高效。头两年对澄清我们在试图实现什么，而不受干扰，是必不可少的。

向开源的转变是一个巨大的改变，也很具教育意义。来自社区的投入是压倒性的。与社区的接触花费了大量的时间和精力，尤其是对Ian，不知怎么他找到时间来回答任何人提出的每一个问题。但它也带来了更多。我仍然惊叹在Alex Brainman的指导下，社区完全独立完成的Windows移植的速度。那很神奇。

我们花了很长时间来理解转向开源项目的影响，以及如何管理它。

特别是，公平地说，我们花了太长时间来理解与社区合作的最佳方式。本次演讲的一个主题是我们的沟通不足——即使我们认为我们正在进行良好沟通——由于误解和不匹配的期望，大量时间被浪费了。本可以做得更好。

但是，随着时间的推移，我们说服了社区中的至少那一部分和我们在一起的人，我们的一些想法，虽然与常见的开源方式不同，但具有价值。最重要的是我们坚持通过强制代码审查和对细节的穷尽关注来维护高质量代码。

一些项目的工作方式不同，它们快速接受代码，然后在提交后进行清理。Go项目则相反，力图将质量放在第一位。我相信这是更有效的方式，但它将更多的工作推回社区，如果他们不理解其价值，他们就不会感到应有的欢迎。在这方面还有很多东西要学习，但我相信现在的情况已经好多了。

顺便说一句，有一个历史细节不是广泛为人知的。该项目使用过4个不同的内容管理系统：SVN、Perforce、Mercurial和Git。Russ Cox做了一份艰巨的工作，保留了所有历史，所以即使今天，Git仓库也包含了在SVN中做出的最早的更改。我们都认为保留历史很有价值，我要感谢他做了这项艰苦的工作。

还有一点。人们经常认为谷歌会告诉Go团队该做什么。这绝对不是真的。谷歌对Go的支持非常慷慨，但它不制定议程。社区的投入要大得多。谷歌内部有一个巨大的Go代码库，团队用它来测试和验证版本，但这是通过从公共仓库导入谷歌完成的，而不是反过来。简而言之，核心Go团队由谷歌支付薪水，但他们是独立的。

包管理

Go的包管理开发过程做得并不好。我相信，语言本身的包设计非常出色，并且在我们讨论的第一年左右的时间里消耗了大量的时间。如果你感兴趣的话，我之前提到的SPLASH演讲详细解释了它为什么会这样工作。

一个关键点是使用纯字符串来指定导入语句中的路径，从而提供了我们正确认为很重要的灵活性。但从只有一个“标准库”到从网络导入代码的转变是坎坷的。

有两个问题。

首先，我们这些Go核心团队的成员很早就熟悉Google的工作方式，包括它的monorepo(单一代码仓库)和每个人都在负责构建。但是我们没有足够的经验来使用具有大量包版本的包管理器以及尝试解决依赖关系图的非常困难的问题。直到今天，很少有人真正理解技术的复杂性，但这并不能成为我们未能从一开始就解决这些问题的借口。这尤其令人尴尬，因为我曾是一个失败项目的技术负责人，为谷歌的内部构建做类似的事情，我应该意识到我们面临的是什么。

我在deps.dev上的工作是一种忏悔。

其次，让社区参与帮助解决依赖管理问题的初衷是好的，但当最终设计出来时，即使有大量的文档和有关理论的文章，社区中的许多人仍然感到受到了轻视。

这次失败给团队上了一课，让他们知道如何真正与社区互动，并且自此取得了很大的进步。

不过，现在事情已经解决了，新的设计在技术上非常出色，并且似乎对大多数用户来说效果很好。只是时间太长，而且道路崎岖不平。

文档和示例

我们事先没有得到的另一件事是文档。我们写了很多文档，并认为我们做得很好，但很快就发现社区想要的文档级别与我们的预期不同。

关键缺失的一部分是最简单函数的示例。我们曾以为只需说明某个东西的功能就足够了，但我们花费了太长时间才接受到展示如何使用它的价值更大。

不过，我们已经吸取了教训。现在文档中有很多示例，大部分是由开源贡献者提供的。我们很早就做的一件事就是让它们在网络上可执行。我在2012年的Google I/O大会上做了一次演讲，展示了并发的实际应用，Andrew Gerrand 编写了一段可爱的Web goo，使得直接从浏览器运行代码片段成为可能。我怀疑这是第一次这样做，但Go是一种编译语言，很多观众以前从未见过这个技巧。然后该技术被部署到博客和在线包文档中。

也许更重要的是我们对Go Playground的支持，这是一个免费的开放沙箱，供人们尝试，甚至开发代码。

结论

我们已经走了很长一段路。

回顾过去，很明显很多事情都做得对，并且它们都帮助Go取得了成功。但还有很多事情可以做得更好，重要的是要承认这些问题并从中学习。对于任何托管重要开源项目的人来说，双方都有教训。

我希望我对这些教训及其原因的历史回顾会有所帮助，也许可以作为对那些反对我们正在做的事情和我们如何做的人的一种道歉/解释。

但在推出 14 年后，我们终于来了。公平地说，总的来说这是一个非常好的地方。

很大程度上是因为通过设计和开发Go作为一种编写软件的方式（而不仅仅是作为一种编程语言）做出的决定，我们已经到达了一个新的地方。

我们到达这里的部分原因包括：

• 一个强大的标准库，可实现服务器代码所需的大部分基础知识
• 并发作为该语言的“一等公民”
• 基于组合而不是继承的方法
• 澄清依赖管理的打包模型
• 集成的快速构建和测试工具
• 严格一致的代码格式
• 注重可读性而非聪明性
• 兼容性保证

最重要的是，得益于令人难以置信的乐于助人且多元化的Gophers社区的支持。

也许这些问题最有趣的结果是，无论是谁编写的Go代码的外观和工作原理都是一样的，基本上没有使用该语言的不同子集的派系，并且保证随着时间的推移代码可继续编译和运行。对于主要编程语言来说，这可能是第一次。

我们绝对做对了。

谢谢。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2024年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

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

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

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