如果 Google 解雇 Go 团队怎么办？

帮我整理这一期英文播客，翻译为通顺的中文，请保留完整内容，不要删减，谢谢！

本篇内容是根据2024年5月份What if Google lays off the Go team?音频录制内容的整理与翻译, 几位Gopher"紧跟时事",讨论了如果 Google 解雇 Go 团队怎么办？ 当然后面就有些偏离主题,讨论起了一些程序员的日常…

过程中为符合中文惯用表达有适当删改, 版权归原作者所有.

Kris Brandow: 大家好，欢迎收听 Go Time。这周我们要谈谈新闻，或者至少是其中的一些内容。这期节目我有两位非常棒的联合主持人。我和 Ian Lopshire 一起主持。Ian，今天你感觉如何？

Ian Lopshire: 我感觉非常好。

Kris Brandow: 很棒。我还和 Johnny Boursiquot 一起主持。Johnny，你怎么样？

Johnny Boursiquot: 还不错。

Kris Brandow: 好的。那么我们有几篇新闻文章——呃，我猜它们都不完全是新闻文章，其中一些是社交媒体上的帖子……不过，我们有很多文章和新闻要讨论。首先是 Reddit 上的一个讨论，关于如果 Google 决定解散核心 Go 团队，会对 Go 的未来采用产生什么影响。

Ian Lopshire: 让我们先来解释一下这个话题的背景……Google 最近的裁员。他们似乎解雇了大量的 Flutter 团队、Dart 团队，还有不少 Python 团队……事情有点疯狂。

Johnny Boursiquot: 这是不是 Google 那种神奇的能力，总是能放弃人们仍然在用且喜欢的产品？他们可能想把这种哲学扩展到语言团队上了。[笑] 这次不仅仅是产品在被砍掉，还包括编程语言和框架。

Ian Lopshire: 我感觉我们需要一个动词来形容 Google 放弃有用的东西，比如 “inboxing”（像他们曾放弃的 Inbox 应用）之类的词……

Kris Brandow: Inboxing……或者还有一个很流行的词，“Google waving”（像他们放弃的 Google Wave 应用）？[笑声]

Johnny Boursiquot: 哦，天哪……如果你年纪够大，记得 Google Wave……嗯，我记得，所以我不想说它的坏话。[笑] 不过，Google 放弃产品有一段时间了，真的。

Kris Brandow: 这是个很好的动词，像 “哦，向这些产品挥手告别吧”。但正如 Ian 所说的那样，这是背景……他们决定裁掉更多的人。这是科技行业的一个有趣时期，大公司在进行大规模裁员，涉及不同的团队……但有了这个背景和上下文后，有很多讨论和想法。我认为 Reddit 上的热门评论，或者说热门回复，基本上在说 “即使他们这么做了也不会有太大的问题，但他们可能不会这么做”。你们怎么看？你们有什么想法？

Johnny Boursiquot: 好吧，Go 是开源的，对吧？所以，我不知道，有很多开源项目——开源的确很好，但我们不能低估那些有公司支持的项目。如果他们没有为这些东西的开发提供资金，不论是直接提供，还是赞助在社区工作的团队或贡献者来让项目保持活力……我们不能低估像 Google 这样的巨头支持者的力量。不过，我认为有足够多的大公司在使用 Go，无论是在基础设施层面，还是在他们的产品中，或者其他地方。所以如果——至少这是我的希望，如果 Google 决定在 Go 领导层上退居幕后，其他公司肯定会争相填补这个位置；他们肯定会想要接手。

现在，治理模式会是什么？目前是 Go 团队决定什么会被采纳，当然也会有社区的意见和贡献，但这是一个集中的公司决策机构。而到目前为止——我对他们做出的一些决定没什么可抱怨的。并非一切都顺利。你不能期望所有事情都顺利。但他们做得还不错。所以如果这一切都改变了，我们不知道新的语言领导层会是什么样的。对 Go 来说，可能会是一个品牌危机，而不是技术上的致命打击。但这也会对领导层带来一些不确定性，直到尘埃落定。

Kris Brandow: 我觉得如果 Google 突然说 “我们不再想做 Go 了，我们要解散整个团队”，我觉得其他大科技公司，比如 Amazon 或 Microsoft，会直接接手整个团队，说 “好吧，那我们来做这个”。微软几乎在 OpenAI 上做了类似的事情，而且那涉及比 Go 团队多得多的人。正如我们稍后会讨论的，微软似乎对 Go 有相当大的投资。

所以看起来会有某种企业赞助者想要接手并继续推进这个项目。即使整个团队被解散，或者成立一个基金会，因为正如 Reddit 帖子中提到的，CNCF 有很多项目是用 Go 编写的。现在已经不可能用另一种语言重写 Kubernetes 了，所以……

Johnny Boursiquot: 有些人会尝试……[笑]

Kris Brandow: 是的，有些人会尝试，但 CNCF 真的会——如果他们要权衡，他们会让 Go 消失，然后尝试用其他语言重写所有项目吗？还是他们会说 “好吧，我们来填补这个空缺”？

Johnny Boursiquot: 相比之下，C 有主要的公司支持吗？C 仍然存在，仍然被使用，并且肯定是我们构建很多技术的基础，所以……

Kris Brandow: 我想 C 是一个标准，所以他们有一个标准组织支持它，就像 C++ 也是一个标准，它也有一个标准组织支持。

Ian Lopshire: 我们也看到过这些语言脱离企业支持者后依然存活下来，对吧？比如 Rust 在 Mozilla 的裁员后依然生存了下来。所以……我不认为这会发生，但即使发生了，我也不觉得有太多值得担心的。

Kris Brandow: 是的，我觉得更让人担心的事情是 Go 团队资源的慢慢枯竭。如果 Google 慢慢减少对 Go 的投资，那你就不得不说 “好吧——” 这几乎比突然说 “我们彻底退出游戏了，再见，我们要关闭这个部门了，剩下的事，世界自己解决吧” 更糟糕。

Ian Lopshire: 裁掉一半的团队比裁掉整个团队要糟糕得多，对吧？

Johnny Boursiquot: 对。如果 Ross Cox 突然被调去做别的事情(译者注: 有那么点一语成谶..)，而 Ian Lance Taylor 也突然说 “我有其他项目了”……或者其他在技术上领导团队的知名人士突然换了角色，或者被调岗……我不知道，那时候我会挠头，想知道 “嘿，这里发生了什么？我们要被放弃了吗，还是怎么回事？”

Ian Lopshire: 我确实好奇模块仓库和 go.dev 网站，文档网站会发生什么……因为这些现在都是由 Google 托管的，对吧？

Kris Brandow: 是的，现在 Google 托管着很多基础设施，肯定得有个计划来迁移它们。但即便如此，我也不认为 Google 会说 “哦，我们要关闭一切”。我觉得他们可能会做一些类似 Google Domains 的事情，说 “好吧，我们要找到其他愿意接手的人”。

Johnny Boursiquot: Squarespace 现在托管 go.dev。[笑]

Kris Brandow: 我肯定会被 Amazon 或 Microsoft 接手……

Ian Lopshire: 现在是 go.squarespace.com。

Johnny Boursiquot: [笑] 太搞笑了。哦，天哪……一些广告，比如 “来看看你在查看漏洞时的推荐商品。”

Kris Brandow: “哦，是的，你可以在他们漂亮的编辑器中编辑 Go 网站。”

Johnny Boursiquot: [笑] 一些广告和商店在你的 go.mod 文件中自动推荐给你。“看看这些鞋子，打了五折。”

Kris Brandow: “你导入了这个模块，导入这个模块的人喜欢意大利千层面。所以这里有一些不错的冷冻千层面供你购买。”

Johnny Boursiquot: [笑] 哦，天哪，太搞笑了。我笑出眼泪了。拜托，Google，别这样做。

Kris Brandow: 我不认为 Google 会把 Go 卖给 Squarespace。我觉得我们没事。

Johnny Boursiquot: 哦，天哪……

Ian Lopshire: Google 能卖 Go 吗？这是他们能做的事吗？

Kris Brandow: 我想他们拥有版权，所以……是的？虽然有点奇怪，但我觉得他们可以……

Johnny Boursiquot: 他们拥有品牌，是的。

Kris Brandow: 没错。创建 Go 的人当时在 Google 工作，而 Google 的合同是那种 “我们拥有一切” 的全包合同。

Johnny Boursiquot: 所以 Go 是开源的……那么开源的知识产权法是什么样的？开源意味着你可以自由使用它，进行各种重用，对吧？这是否意味着——

Kris Brandow: 这意味着如果你 fork（分支）了它，你不能称它为 Go？就像 Terraform 的情况一样，他们 fork 了 Terraform，但他们不能叫它 Terraform，因为 Terraform 是 HashiCorp 的知识产权。所以 Go 是知识产权；它的品牌是知识产权。

Ian Lopshire: 等等，谁 fork 了 Terraform？我们稍微偏题了……

Kris Brandow: CNCF fork 了它，叫 OpenTofu……

Johnny Boursiquot: Ian 最近住在石头下吗？[笑] (译者注: 这句话在揶揄Ian Lopshire消息滞后)

Kris Brandow: 也许我们应该多做点这类话题。

Ian Lopshire: 这是他们卖给 IBM 之后发生的吗？

Johnny Boursiquot: 不，那是在很久之前。大概是六个月前的事。

Ian Lopshire: 我怎么错过了这个？我也不知道。

Johnny Boursiquot: 是啊，可能因为你不怎么用 Terraform。

Kris Brandow: HashiCorp 做了 Redis 做过的事——或者说 Redis 做了 HashiCorp 做的事，采用了双重许可模式，每个人都说 “不行”。然后一群人聚在一起 fork 了 Terraform，搞出了 OpenTofu。

Ian Lopshire: 好的，又多了一件要加到我的阅读列表中。

Kris Brandow: 是的。幸运的是，只有一个 fork，不像 Redis，有那么多。

Ian Lopshire: 现在有一个 Apache 版的 Redis，对吧？

Kris Brandow: 有很多个。好了，我们偏题了。

Johnny Boursiquot: 哦，我肯定 Redis 有很多个 fork……我妈妈可能都有一个 Redis 的 fork。[笑] 所以没事。如果 IBM 恢复了整个 Terraform 许可的问题，那就有趣了……

Kris Brandow: 我想我读到过 IBM 确实有一个 Terraform 的 fork，一个开源的 fork，每个人都在说 “嗯？” [笑声] 这是个有趣的情况。所以我猜问题的答案是肯定的，你可以卖 Go，或者至少卖它的知识产权。我想如果你卖给像 Oracle 这样的公司，他们肯定会想办法把它变成闭源的，但(译者注: 看起来Oracle的风评海内外很一致..)……我觉得其他公司会带着它继续前进，说 “好吧……”

Johnny Boursiquot: 是的，也许吧。

Ian Lopshire: 好吧，让我们屏住呼吸，祈祷这不会发生……

Johnny Boursiquot: 是的，但是哪部分？所有？

Ian Lopshire: 特别是 Squarespace 的那部分……但确实是所有部分。

Johnny Boursiquot: 好的，没问题，大家都同意。哦，天啊……是的。

Kris Brandow: 我觉得我们目前还是相当安全的，Google 不太可能放弃 Go。而且从贡献的角度来看，我觉得大部分核心贡献来自 Google 之外。所以这并不会让语言的开发速度变慢。你只需要找到一个新家，正如 Johnny 你之前提到的，你需要一个新的治理模式，来决定提案如何进行，以及哪些大功能能进入核心语言，而不是那些人们只是维护的库之类的小功能。所以，是的，我觉得这会很有趣。但就目前而言，我们是安全的。没有 Go 被卖给 Squarespace 的风险。

Johnny Boursiquot: 至少我们知道的范围内是没有。我们三个只是在播客上胡乱猜测一个大公司可能会做或不会做什么。他们正在裁掉整个语言团队和框架。你能想象如果你是 Flutter 或 Dart 团队的成员吗？你花了几年的时间在这些框架和语言上，然后突然有个公司高管说 “嗯，我们现在需要把资金转向 AI。其他这些东西不是核心业务，不符合我们的目标。” 然后就因为一句话，你的生计就岌岌可危。你能想象吗？

Kris Brandow: 嗯，是的，但……

Johnny Boursiquot: 千万不要把所有鸡蛋放在一个篮子里，朋友们。千万不要这样做。永远不要。

Kris Brandow: 是啊。我觉得会很有趣，尤其是随着所有这些 AI 的发展，看看一切会走向何方……

Johnny Boursiquot: 说到可能会拯救 Go 的企业赞助者……我们这里是不是有关于 Microsoft 的故事？

Kris Brandow: 是的。Johnny，这个过渡非常好。我们有一篇来自 Microsoft 的博客文章，讲的是他们启动了一个 Go 部落格……不过他们还悄悄提到，他们基本上有一个内部使用的 Go fork，并且他们正在将一些改动推送到上游……这非常有趣。我觉得这并不常见，但也不算罕见，公司会有自己的内部 fork，用来做一些小调整，或其他事情……不过我觉得他们的 “我们会尽可能将改动推送到上游” 的理念很有趣。你们怎么看？

Ian Lopshire: 首先，这已经不仅仅是一个内部 fork 了。现在是公开的。如果你愿意的话，你可以使用它。

Johnny Boursiquot: 它的 goroutines 是不同的吗？它是不是会调用 C#？[笑]

Ian Lopshire: 不，如果你真的去读一下它的内容……基本上只是一些为了符合政府标准的加密改动。

Kris Brandow: 像 FIPS 标准之类的？

Ian Lopshire: 我不知道 FIPS 是什么，但……FIPS 140-2。

Johnny Boursiquot: 你不熟悉 FIPS 140-2 吗？

Ian Lopshire: 不，我不熟悉……

Johnny Boursiquot: 没人熟悉，伙计……[笑] 除非这是你每天的工作，否则我想没人会注意这些东西，除非他们必须这样做。

Ian Lopshire: 我想这和政府合同有关。

Kris Brandow: 是的。它是联邦信息处理标准。

Johnny Boursiquot: 我猜如果你是为政府工作的工程师，这些东西对你会很熟悉。

Kris Brandow: 是的。它是针对非军事政府机构和承包商的标准。

Johnny Boursiquot: 所以我猜你是说政府机构和军工承包商会使用不同的东西。

Kris Brandow: 嗯，是的。军工机构和承包商……

Johnny Boursiquot: 不公开。

Kris Brandow: ……使用的东西可能更高级、更安全。我也不知道。

Johnny Boursiquot: 是的，更加保密。你不想把这些信息透露给敌人。是的，是的。

Kris Brandow: 机密。

Johnny Boursiquot: 是的。我们回到新闻上吧。[笑]

Kris Brandow: 是的，所以我觉得微软在 Go 上的投资态度越来越坚决，这很有趣。我觉得这也是他们试图重新成为一家大型开源公司的整体轨迹的一部分，就像他们收购 GitHub 时的举措，还有其他一些事情……我记得 GitHub 在 Go 上也有很多投资，对吧？所以我觉得他们可能从那儿得到了很多 Go 的投资。是的，我觉得这很有趣。更多的 Go 版本听起来也不错。我们现在有两到三个大版本……

Johnny Boursiquot: 这是个不受欢迎的观点吗？我们已经跳到那个部分了吗？更多的 Go 版本？

Kris Brandow: 抱歉，不是版本……更多的 Go 实现。

Johnny Boursiquot: 你为什么想要更多 Go 的实现？你不喜欢现有的那个吗？

Kris Brandow: [笑] 我喜欢我们现有的版本，但我们已经有三个了……至少有两个……哦，我猜是三个。如果你数的话。我们有 GCC 编译器，这是主要的 Go 编译器，你有 GCC Go，还有 TinyGo……而且还有其他几个。是不是有一个可以和 GNU 编译系统一起工作的？GCC Go。还有 llgo，那是我在想的另一个。是的，有很多不同的版本——不是版本。是很多不同的 Go 实现，这是设计者们本来就打算的。所以再添加一个进去似乎没什么问题。

Johnny Boursiquot: 好的。那我可以接受。

Kris Brandow: 我的意思是，如果你不同意的话，Johnny，你可以表达不同意见……

Johnny Boursiquot: 不，不，我接受。[笑]

Ian Lopshire: 我想知道谁在用这些其他实现。

Kris Brandow：我知道根据你所针对的架构，可能会有人使用不同的编译器，比如 GCC Go 或者 LLVM Go（llgo），这些编译器的后端可能有标准 Go 编译器没有的支持。曾经有一段时间，Go 编译器没有支持 IBM 的 Z 架构（大型机架构），但 LLVM 的后端支持了，所以人们会用 llgo 来编译这些架构上的代码。或者如果你想要与其他语言兼容，或者需要更好用的方式，你也可以选择这些替代编译器。当然，对于像 TinyGo 这样的项目，如果你想在微处理器上运行 Go，你就不希望生成一个 80 兆字节的二进制文件。[笑]

Ian Lopshire：对啊，那你觉得这对 Go 有什么影响呢？在他们的公告中提到，他们会发布一些关于在 Azure 上运行 Go 工作负载的消息。我觉得我们会看到更多的兼容性。我不使用 Azure，所以我不太清楚 Go 在 Azure 上的表现如何……不过我知道 AWS 有一些不错的内置支持。你是用 Go 跑 Lambda 的，对吧？

Kris Brandow：是的，我猜他们更多的产品会原生支持 Go……我想他们应该已经有不少 Go 的积累了，我的感觉是，任何跟 Kubernetes 集成的项目，如果你在做这类工作，可能你很多工作都是用 Go 写的，所以你的云基础设施团队应该已经有相当多的 Go 专业知识了。

很多 CNCF（云原生计算基金会）项目都是用 Go 写的。实际上，很多云相关的项目都是用 Go 写的，我觉得不可能有一家云公司对 Go 完全不熟悉。

Johnny Boursiquot：如果你做任何与云相关的事情，不管你是否直接与它互动，可能你在你的技术栈中某个地方已经在用 Go 了。我觉得这点现在相当确定。

Kris Brandow：是的。三大云服务提供商都有 Kubernetes 系统和产品，所以……这本身就很棒。是的，看到其他公司也在进行投资，这很令人兴奋。我想这也有助于我们之前讨论的内容，减少了某个公司可能对 Go 造成致命打击的风险。因为如果微软在接下来的几年间确立了自己作为 Go 的大贡献者的地位，那么如果某天 Google 不想再继续做这个项目了，很明显微软可以成为接班公司，继续推动 Go 的发展。

Johnny Boursiquot：是的，我觉得这整体上是好事。我之前开玩笑说，突然间在微软的 Go 工程团队找份工作似乎也不是个坏主意。他们需要有人在内部推广这些东西，对吧？[笑]

Kris Brandow：我意思是，现在的微软可不是以前的那个微软了，不再是 Johnny 开始编程时那个古老的时代了。

Johnny Boursiquot：你知道的，现在是个完全不同的世界。我记得那个时候我还在用软盘安装 Windows……

Kris Brandow：那些 Windows 软盘……

Johnny Boursiquot：那可不是现在的时代了……[笑] 那些软盘已经不再用了……

Ian Lopshire：那是多久以前的事？

Johnny Boursiquot：别问了，别问了……拜托……[笑]

Ian Lopshire：我无法想象 Windows 是装在软盘上的。那得有 30 张盘吧？

Kris Brandow：确实是个不小的数量，没错。

Johnny Boursiquot：差不多是这个数。

Kris Brandow：安装起来真是让人抓狂……

Ian Lopshire：每次 4 兆字节装一个 Windows 系统。

Johnny Boursiquot：是啊。现在插入第 17 张盘。[笑] 你按下加载键，弹出第 16 张盘……

Ian Lopshire：那软盘容量是 4.3 兆字节吗？我记得对吗？

Johnny Boursiquot：哦，容量随着时间有所变化。具体取决于你什么时候开始接触这个领域。也许你接触的是 5.5 英寸，还是 5.25 英寸？

Kris Brandow：5.25 英寸和 3.5 英寸……

Johnny Boursiquot：对，然后我们缩小到了 3.5 英寸的大小，或者别的什么……但中间我们经历了各种存储介质，像 ZIP 驱动器，磁带等等……我觉得现在的孩子们完全不知道自己有多幸运。

Ian Lopshire：ZIP 驱动器实际上是磁带吗？

Kris Brandow：不，ZIP 驱动器还是磁盘存储设备……

Ian Lopshire：哦，是吗？

Kris Brandow：是的……只是一个更高级的存储设备。因为我成长在 ZIP 驱动器和软盘的时代。高中时，我们必须把所有的 Word 文档保存到软盘上，交作业之类的。我不想回忆那个时代。然后出现了 U 盘，一切就改变了。

Johnny Boursiquot：那确实是个改变。我记得当时一个 5 兆字节的 U 盘就要 50 美元左右。

Kris Brandow：80 美元吧。

Johnny Boursiquot：是的，价格非常高。但当时你会觉得“哇，5 兆字节？！你知道可以存多少东西吗？那大概能存 12 个《德军总部》游戏。”简直不可思议。[大笑]

Ian Lopshire：德军总部……

Kris Brandow：哇，5 兆字节——现在相当于一张照片的十分之一。[大笑] 但回到微软的话题上……[大笑]

Johnny Boursiquot：这些话题偏离得太远了，不过很有趣，也很娱乐……

Kris Brandow：这是来自 90 年代末的微软。不过看到这一切真的让人欣慰。几年前，微软宣称他们要成为更好的开源贡献者，要为过去的错误赎罪，当时大家都有些怀疑。但后来他们收购了 GitHub，大家又开始担心“GitHub 会不会变得奇怪？我们会不会在 GitHub 上看到 Clippy？”不过我觉得他们处理得还不错。所以看到他们继续朝这个方向发展，真是件好事。

Ian Lopshire：是的，这感觉就像他们一直在延续这种路线。他们做了 .NET Core，收购了 GitHub，还为 Windows 引入了 Linux 子系统……所以我很期待看到他们在 Go 方面的投入。

Kris Brandow：是的，这部分确实不错。你可以看到他们所做的事情以及他们的做法正逐渐变得更好。感觉不错，他们没有把地毯从我们脚下抽走。(译者注:pull the carpet out,英文习语, 大意类似猝不及防,措手不及)

Ian Lopshire：我觉得 GitHub 被微软收购后变得更好了，像是推出了无限制的免费私有仓库……我很喜欢这个。

Kris Brandow：价格确实便宜了。我记得当时觉得“每月 4 美元就能获得这么多服务？太棒了。”

Kris Brandow：接下来呢，接下来我们会聊……哦，对了，这篇来自 Go 官方博客的有趣文章，关于标准库的演变，首个 v2 包是 math/rand 的新版本。我觉得这真的是期待已久的一步。我一直不太喜欢 math/rand 的工作方式，尤其是——我理解他们为什么要让它跟 crypto/rand 不一样，这样你就不可能意外地使用错误的库，但这仍然非常烦人。如果你想使用伪随机数生成器而不是加密级别的随机数生成器，必须使用完全不同的 API。

不过我觉得这是一个很有趣的下一步，特别是在所有这些年来，我们逐渐看到了 Go 2 的愿景得以实现。虽然 Go 2 不是一个独立的版本，它只是 Go 中增加了一系列新特性来推动语言的进步，但看到标准库能够引入新的功能和变化，同时不打破向后兼容性，还是很令人激动的。

Johnny Boursiquot：这是标准库中的第一个 v2 包。在这么多年后，我们从理论走向了实践，实际运用了 Go 模块包版本管理的概念。

Kris Brandow：那么你有什么看法，Ian？对这个有什么想法吗？

Ian Lopshire：我觉得文章提到了一些有趣的观点，比如关于 v1 和 v2 之间的漂移，我们当然不希望这种情况发生。文章中提到，任何 v2 包在发布时必须能够完全实现 v1 包的功能。所以不会出现 v2 包缺少 v1 包某些功能的情况。我觉得这非常好。文章还提到计划是让 v1 包成为 v2 包的一个薄封装，这样 v1 包可以从 v2 包的更改中获得 bug 修复和更新……我觉得这非常棒。希望这能顺利实现。

Kris Brandow：哦，把 v1 包封装在 v2 包之上——对，明白了。

Ian Lopshire：是的，我觉得这是很聪明的做法，希望能奏效。当然这不可能对所有情况都适用，但……

Johnny Boursiquot：这种方式确实奏效……嗯，奏效在哪儿来着？我在想哪个包用这个方式奏效了？哦，我想到另一个例子。我想到的是 context 包正式引入时的情景。它从实验性变成了标准库的一部分。以前你用 HTTP 包来创建新请求，http.NewRequest对吧？。当 context 包正式引入后，新的 NewRequestWithContext方法就被引入了，而旧的 NewRequest 方法则被改为在后台自动创建一个 context，这样每个请求都会默认有一个 context。这种方式很好，语言中引入了新特性，而你的代码不需要大的改动。我觉得这是个很好的做法。但正如你所说，Ian，有些 API 变化太大，比如增加了新的参数，或者某些数据类型不再需要，或者有某些值不再是必需的……在这些情况下，可能无法简单地兼容旧的 API。我觉得我们可能会看到像 math/rand 包那样，必须引入一个 v2 版本来实现新的能力。

译者注:

在 Go 语言中，context 包的引入是为了提供一个标准的方式来管理请求的取消、超时和传递请求范围的元数据。在 HTTP 请求处理中，context 尤其有用，因为它允许开发者在多个 goroutine 之间传递控制信息，并且可以在某个请求被取消或超时时，自动取消相关操作。

在 context 包引入之前，Go 语言的 HTTP 请求处理是没有标准化的机制用来处理超时或取消请求的。开发者需要自己手动管理这些逻辑，比如通过传递某种标志或手动处理超时逻辑。

旧的 http.NewRequest是在 context 包引入之前，Go 的 net/http 包中一个常用的函数：

req, err := http.NewRequest(method, url, body)

这个函数用于创建一个新的 HTTP 请求对象 (http.Request)，但它并没有直接处理与取消请求或超时相关的需求。

而新的 http.NewRequestWithContext是在 context 包引入后，Go 增加的一个新函数：

req, err := http.NewRequestWithContext(ctx, method, url, body)

这个新函数允许你为 HTTP 请求附加一个 context.Context 对象。通过传递一个 context，你可以控制请求的生命周期。例如，当 context 被取消或超时，HTTP 请求也会被取消。

旧有http.NewRequest 的改进:

为了保持向后兼容，Go 团队没有移除旧的 http.NewRequest 函数，而是对它进行了改进。现在，当你使用旧的 http.NewRequest 函数时，Go 会自动为你的请求附加一个默认的 context。这个 context 是在后台自动创建的，实际上是一个基于 context.Background() 的上下文。

这意味着，即使你没有明确使用 http.NewRequestWithContext，Go 也能确保每个 HTTP 请求都有一个 context，从而让开发者可以更方便地管理请求的生命周期。

例如:

使用旧的 http.NewRequest：

req, err := http.NewRequest("GET", "http://example.com", nil)

使用新的 http.NewRequestWithContext：

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()

req, err := http.NewRequestWithContext(ctx, "GET", "http://example.com", nil)

在第二个例子中，HTTP 请求会在 2 秒超时后自动取消。

即

• 旧的 http.NewRequest：现在会自动附加一个基于 context.Background() 的默认 context。
• 新的 http.NewRequestWithContext：允许你明确地为请求传递一个 context，从而更灵活地控制请求的生命周期。

通过这种方式，Go 保持了向后兼容性，同时提供了更强大的 context 支持来改进 HTTP 请求的管理。

幸运的是，我确实喜欢这种方式。从根本上来说，这正是 Go 向后兼容性承诺的体现。我们不打破现有代码。当 API 发生变化，或者某个功能的行为发生了根本性的改变时，我们依赖 v2 包。我觉得不仅仅是标准库需要这样做，像 linters 这样的工具也会对此产生影响。

最近我试着初始化一个随机数生成器，不确定是哪个 linter 抓到了问题——我现在大概有十几个 linter——但它告诉我：“嘿，你不需要再用时间来做种子初始化了，直接使用 math/rand 就行。”这让我感到很高兴，我想“哦，对，这个特性在今年 3 月就引入了。”我已经习惯于以前的做法，没意识到我还在用旧的方法，或者我甚至没意识到你可以用新的更好的方式。所以我的 linter、编辑器和开发环境帮我跟上了最新的变化。我觉得整个生态系统都需要共同努力，引导大家向新的方式靠拢。

Ian Lopshire：是的，我觉得这正好体现了语义导入版本管理的一个巨大优势……v1 和 v2 可以共存于同一个代码库中，你可以逐步迁移。 所以像你说的那样，现在你可以开始使用 v2，而不需要改变所有东西。

Kris Brandow：是的。我也觉得 go.mod 文件中增加 Go 语言版本这一功能非常有用，这让他们可以修复很多之前难以修复的问题，或者那些过去需要通过 v2 包或语言的 v2 版本来解决的问题。 我觉得最近去掉的那些 shadowing（变量遮蔽）问题就是一个例子。以前要修复这些问题非常困难，但现在你可以通过编译器的版本来处理：“哦，你在用老版本的语言，我们会保持旧的语义”，或者“哦，你在用新版本的语言，那么语义会有所不同。”

还有我一直想要的，在range中直接使用数字的功能……[笑] 能够做这些事，并且根据编译器版本来检测功能的可用性，我觉得这可以确保我们不会急于推出 v2 包，只有在真的需要做一些根本性不同的事情时，才会去引入 v2 包，而不是因为“我不喜欢这个索引”或者“我不喜欢这个特定的东西”。

Ian Lopshire：你们对即将推出的 v2 包有什么期待吗？

Johnny Boursiquot：我觉得不会有人对 v2 包感到兴奋吧……这只是我们现有的系统……

Kris Brandow：是的，我不喜欢语义导入版本管理……

Johnny Boursiquot：……爱你所拥有的吧。[笑]

Kris Brandow：我觉得语义导入版本管理还是有些问题……不过既然我们只有这个选择，那也就只能接受了。

Ian Lopshire：我现在还挺喜欢它的……

Kris Brandow：我没怎么用过，因为我觉得很多人都固定在 v0 或 v1 上以避免这个问题……但当时有些模块已经到了 v5 版本，它们有一大堆包，要用 go imports 来导入正确的包真的很麻烦。我不知道这个问题是否已经解决了，但这确实是我当时最头疼的事情之一。写代码变得更加烦人，因为语义导入版本管理是针对单个包，而不是整个模块……我觉得这种做法没问题，但还是存在很多问题。不过我觉得这可能对标准库来说没什么大问题，因为标准库不会有那么多版本更新——可能要很长时间才会有某个包的 v5 版本。而且我觉得他们会非常小心，确保你导入的包是正确的版本。

Ian Lopshire：如果我们有一天真的到了 v3，我会感到很惊讶……因为他们不会轻易对包进行 v2 升级，除非有非常必要的原因。

Johnny Boursiquot：听着，Ian，你活得够久，意想不到的事情就会发生。比如我们已经没有 ZIP 驱动器了，对吧？[笑] 所以别太早下结论，给它点时间。坚持下去。

Ian Lopshire：好吧，那我们打个赌，十年后再看看谁说得对。

Johnny Boursiquot：[笑] 我们会有个一千集纪念节目之类的……然后我们这些老家伙会被邀请回来，聊聊“在我们那个年代，v2 是我们能期望的最多的版本。”

Kris Brandow: 是的。我觉得这很有趣，因为你真正需要 v2 的唯一理由是你想重复使用一个名称……否则，你只需创建一个新的包并赋予它一个新名称，对吧？如果你觉得“哦，这个是更高级的版本”，那就说“好的，这是新的名称”。就像他们对 fs 包所做的那样，他们只是说“好了，我们为这个新东西创建一个新包和新名称”。这并不像什么 os v2 包。

Johnny Boursiquot: 或者你可以像某些项目那样……他们基本上说“听着……下次你执行 go get 时，即使包路径相同，你获得的也会是 v2 版本。” [笑声] “如果你想要 v1 的东西，最好绑定到某个提交哈希，老兄……”

Kris Brandow: 哦天哪，那些糟糕的旧日子……

Ian Lopshire: 我刚刚为我正在做的某个项目添加了一个包，我记得它的版本号好像是 44……当时我非常困惑。我真希望我能记得它是什么……

Kris Brandow: 我猜有些人只是觉得“哦，语义化导入版本管理。我们就疯狂使用它吧。”

Kris Brandow: 我认为这是我们行业中一个有趣的挑战……我对语义化导入版本管理和许多其他东西有一些抱怨……但这感觉像是我们行业中做得较好的一种方式。我们基本上成功地将 Go 迁移到 Go 2 版本，就像“这是 Go 版本 2”，但实际上并没有任何重大破坏性变化……我认为这很不可思议，因为我们并没有遇到像 Python 那样的问题，或是其他许多语言遇到的问题，类似于“哦天哪，我们有几年非常糟糕的时间，因为我们不得不一次性做出所有这些变化，大家都对我们很生气，所有人都被旧版本困住了十年，我们也不知道该怎么办……”

但对于 Go 来说，好像你并不会被老版本困住太久，因为你可以前进。而且我认为这也部分归功于 Go 的历史，比如 gofix 工具，以及一些其他的东西，比如“好的，我们将自动重写你的代码，帮助你升级到新版本。"

Johnny Boursiquot: 感谢上帝我们没有像 JavaScript 社区那样到处创建 polyfills、转译器、各种工具……JavaScript 社区真是……

在 JavaScript 中，Polyfills 是一种用来“填补”旧版本浏览器或环境中缺失功能的技术手段。它们通常是一些代码（通常是 JavaScript 函数或库），用于模拟在较新版本的 JavaScript 中才引入的特性，以便在不支持这些特性的旧浏览器中也能正常运行。

为什么需要 Polyfills？

随着 JavaScript 语言和 Web 标准的不断演进，浏览器逐渐支持了许多新特性，例如 ES6（ES2015）中的 Promise、Array.prototype.includes() 等。然而，旧版本的浏览器并不支持这些新特性。如果你希望你的应用程序能够在这些较旧的浏览器中也正常工作，就需要使用 Polyfills 来模拟这些特性。

Polyfills 的工作原理

Polyfills 的作用是检测当前环境是否支持某个特性，如果不支持，就通过自定义实现来提供一个替代方案。例如，如果浏览器不支持 Array.prototype.includes() 方法，Polyfill 可以定义一个等效的功能来“补充”这个缺失。

示例：Array.prototype.includes 的 Polyfill

假设你在一个不支持 Array.prototype.includes 方法的旧浏览器中运行代码，可以通过添加 Polyfill 来确保功能正常：

if (!Array.prototype.includes) {
  Array.prototype.includes = function(searchElement, fromIndex) {
    if (this == null) {
      throw new TypeError('"this" is null or not defined');
    }

    // 1. 转换为对象
    var o = Object(this);

    // 2. 获取长度
    var len = o.length >>> 0;

    // 3. 如果长度为 0，直接返回 false
    if (len === 0) {
      return false;
    }

    // 4. 起始索引处理
    var n = fromIndex | 0;
    var k = Math.max(n >= 0 ? n : len - Math.abs(n), 0);

    // 5. 遍历数组
    while (k < len) {
      if (o[k] === searchElement) {
        return true;
      }
      k++;
    }

    // 6. 如果找不到元素，返回 false
    return false;
  };
}

常见的 Polyfills 示例

1. Promise Polyfill：一些老旧的浏览器（如 IE11）不支持原生的 Promise，可以使用 promise-polyfill 等库来提供支持。

2. fetch API Polyfill：早期浏览器不支持 fetch API，可以使用 whatwg-fetch 库作为 Polyfill。

3. Object.assign Polyfill：对于不支持 Object.assign() 的浏览器，可以通过 Polyfill 模拟该方法。

使用 Polyfills 的方式

1. 手动编写 Polyfill：像上面那样手动为某个特性编写 Polyfill。

2. 使用第三方库：例如，core-js 是一个常用的 Polyfill 库，涵盖了大量的 ES5、ES6 以及其他新标准的功能。

3. Babel：Babel 是一个非常流行的 JavaScript 转译器，它可以将现代 JavaScript 转换为兼容旧版浏览器的代码。Babel 还支持自动添加 Polyfills，例如使用 @babel/preset-env 来根据目标环境自动引入所需的 Polyfills。

加载 Polyfill 的策略

为了确保性能，通常不要在所有环境中都加载所有 Polyfills，常见的策略包括：

1. 按需加载：使用特性检测（feature detection）来判断当前浏览器是否需要某个 Polyfill，如果功能缺失才加载 Polyfill。

2. 使用 Polyfill 服务：例如 polyfill.io，根据用户的浏览器动态加载所需的 Polyfill。

即

• Polyfills 是用来模拟较新 JavaScript 功能以支持旧版本浏览器的代码。
• 它们通常用于填补浏览器中缺失的原生 API（如 Promise、fetch 等）。
• 可以手动编写 Polyfill，或使用第三方库（如 core-js 或 @babel/preset-env）来自动处理。

通过使用 Polyfills，开发者可以确保他们的代码在更广泛的浏览器环境中正常运行。

Johnny Boursiquot: 要友好一点，友好一点，友好一点……

Kris Brandow: ……他们采取了一种有趣的方法，感觉他们的标准库并不多，所以有一大堆包，而且这些包都依赖于其他包……但这似乎奏效了。JavaScript 并没有像 Python 那样遇到同样的破坏性变化问题，他们在时间的推移中大大改进了这门语言。所以我认为这是解决同一问题的另一种方法……但我认为 Go 采取的这种方法只有在你对语言有某种集中控制的情况下才有效。如果你有 Go 团队来做出所有这些决定。我觉得如果你采用一种更具代表性的民主方式来做事，那就会难得多，最终很难确保你在正确的道路上前进……所以我认为 JavaScript 所做的事情可能是他们那种社区能够做到的事情。而且它有效，所以……

Johnny Boursiquot: 而且公平地说，有些人确实是出于好意，想要推动语言和社区前进，但你有很多既得利益者—基本上，他们通过现状赚钱。这在任何事物中都是同样的问题。每当你需要对某事做出改变时，改变会带来破坏性。有人通过现有的事物建立了整个业务，可能是浏览器制造商、插件供应商等等。人们不喜欢改变，因为每当你改变这些东西和底层技术时，这意味着他们现在不得不投入更多的成本来适应和改变他们的产品……这意味着他们赚的钱会减少。股东的暴政，你懂我的意思吗？你不能不断增加成本而不给股东钱。

这让我想起了我职业生涯早期学到的一个有趣的教训，当时我意识到技术决策很少是纯粹的技术决策。我会提出一个非常有说服力、结构良好的建议，逻辑上是关于从这个框架切换到那个框架，从这种语言切换到那种语言，或者从这种架构风格切换到另一种的提议，等等，并提供清晰的迁移路径……不是摧毁一切，而是进行增量更改……发布计划，路线图……我做了所有这些工作，然后他们会说“哦，是的，我们会接手的。”然后决定是在某个我不在的房间里做出的，我意识到“什么？！你们选择了这个方案？但这完全没有道理。从技术上讲，这是一个糟糕的决定。你们根本不知道自己在做什么。”我真的会对此感到生气，然后有一天我突然意识到“该死，这并不总是关于技术决策，对吧？”还有其他我不了解的因素影响这些决定。所以，是的，即使在开源社区中，也会有既得利益者，他们不希望事情发生太大变化，因为他们有很多利益相关。

Kris Brandow: 是的。我认为这就是为什么fork是件好事。我记得在我最后几年（也许是去年）活跃于 Drupal 开发时，有一场关于 Drupal 新版本的大讨论；它将会是 Drupal 8，将会改变一切……但有很多人说“我们其实挺喜欢 Drupal 7 的工作方式，以及 Drupal 的历史工作方式……所以我们干脆fork一下，做另一个东西。”看起来两者都在蓬勃发展。所以就像“好吧，如果你想要旧的东西，那就去用这个 Backdrop 项目；如果你想要新的东西，那就去用新的 Drupal。” (译者注: Drupal 是一个开源的内容管理系统（CMS），用来构建和管理网站的内容，使用 PHP 编写)

Johnny Boursiquot: 等一下……我要去fork Redis 了。[笑声] 说到这个，我们的新闻列表里是不是有另一个 Redis 克隆？

Kris Brandow: 是的，是的，我们有。

Johnny Boursiquot: 当然有。

Kris Brandow: 关于 math/rand v2 包或者 Go 的演变，有什么最后的评论吗？

Ian Lopshire: 仅是一个想法……我很想看看 Go 的第一个版本与现在的对比。它真的变化很大吗？

Johnny Boursiquot: 去看看提交历史吧。

Kris Brandow: 你是指有人写 Go 的时候，比如……

Kris Brandow: 哦，从 2009 年开始？

Ian Lopshire: 2009 年到现在。肯定有变化，但没有那么大。如果你问 Mat Ryer，他可能会告诉你，因为他一直在写“我这样写 Go 已经 20 年了”之类的东西……

Ian Lopshire: 他说 13 年了，是的。

Johnny Boursiquot: 30 年，是的。

Kris Brandow: 20 年后，Johnny，Go 语言还没有 20 年历史呢。

Johnny Boursiquot: [笑] 我在用招聘人员的数学方法，抱歉。所以在写了 32 年的 Go 之后……[笑声] 我仍然在处理我的路由，之类的，对吧？

Kris Brandow: 我觉得从 Go 的初始开源版本到 v1.0 版本之间的差异可能会比 Go 1.0 到现在的差异要大。我觉得那个变化会更加明显。比如，我们现在有了 context。还有一些其他的东西。但最初几年里的变化可能更多是“哦，这个——”首先，它可能根本无法用现代编译器编译……而使用 Go 1.0 写的东西理论上应该仍然可以编译。所以是的……但那会很有趣。应该有人去写篇博客文章讲讲这个。

来说说更多的fork项目吧。Redis。我们有一个用 Go 重新实现的小 Redis，它的后端使用了 SQLite。

Johnny Boursiquot: 你叫它 SQLite？等一下，等一下。我觉得我们即将展开另一场辩论……

Kris Brandow: 我在 SQLite 和 SQLite 之间摇摆不定……

Johnny Boursiquot: 你叫它 GIF 还是 GIF？

Kris Brandow: 我在 SQLite 和 SQLite 之间摇摆不定……但如果我们要非常讲究的话，它应该叫 SQLite，因为语言叫 SQL。

Johnny Boursiquot: 你叫它 SQL？每次你提到 SQL 时。

Kris Brandow: 是的，大多数时候我叫它 SQL。有时我会叫它 Sequel。但大多数时候我叫它 SQL。

Ian Lopshire: 唯一比 SQL 更糟糕的是当有人叫它 squeal，或者——

Johnny Boursiquot: Squeal……[笑声]

Ian Lopshire: 我听过有人这么叫，太糟糕了……

Kris Brandow: Squeal Lite！但不，这里有历史原因，它叫 SQL 是因为有另一种语言叫 Sequel，被注册了商标，所以他们不能叫它 Sequel。于是他们叫它 SQL。

Johnny Boursiquot: 但如果你知道，你就知道。(译者注: 津津乐道 争论sql读音)

Kris Brandow: 就像叫纸巾 Kleenex 一样。

Johnny Boursiquot: 是的，我们一直在进行这些辩论。从古至今。就像我们会说“不是的，服务器无关并不意味着没有服务器。”我们总是进行这些对话。但最终你会说“你知道吗，我懒得再和市场营销人员争论了，就这样吧。”[笑声]

Kris Brandow: 我觉得问题的关键在于英语并不是一种拼音语言。你不能通过看一个单词就知道它应该怎么发音……这就是一半的战斗。

Johnny Boursiquot: 有些山头我不愿为之牺牲。我没时间。

Kris Brandow: 你怎么发音？你怎么发那个图片格式的名字？是 GIF 还是 GIF？

Johnny Boursiquot: 好吧，你提到的那个神——你会叫他 Geod 吗？

Kris Brandow: [笑] 那不是发音的规则，Johnny。G 可以发 ge 或 ga 音。

Johnny Boursiquot: 是的，是的……我有个朋友叫 George。我不会叫他 Gorge，尽管这有点搞笑……[笑声]

Ian Lopshire: 我还挺喜欢这个的。

Kris Brandow: 是的，我想这就是区别：你是把它看作 GI F 这个单词，所以你有个 GI——这应该发 ga 音——还是你把它看作 gr 单词，发 ga 音。gea 还是 ga？我不知道，这不重要。这真的不重要。这是最愚蠢的争论之一。

Johnny Boursiquot: 你知道什么不是愚蠢的争论吗？Tab 还是空格？慎重选择。

Kris Brandow: Tab，因为我们在写 Go。你什么意思？

Johnny Boursiquot: 好吧。是的，我们还是朋友。[笑声]

Kris Brandow: 你根本不能使用空格。我不知道……

Johnny Boursiquot: 虽然你可以配置编辑器，每次你按下 Tab 键时，添加四个空格……[笑声]

Kris Brandow: 然后 go fmt 会把它变回 Tab。

Johnny Boursiquot: [笑声] 那些人可能讨厌 go fmt。他们可能不做 Go 了。

Kris Brandow: 我的意思是，如果你是个死忠的空格爱好者，那……不管怎样，我们不是应该在讨论 Redis 吗？

Johnny Boursiquot: 是的，我们是。

Kris Brandow: 我们完全跑题了……所以，我不知道，你们对所有这些新的 Redis 分叉项目有何看法？或者特别是这个……

Johnny Boursiquot: Redka。

Kris Brandow: Redka。

Johnny Boursiquot：好的部分……所以你已经很有看法了。Redis 和 SQLite 的好的部分。

Kris Brandow：相对于坏的部分来说。

Johnny Boursiquot：你知道这些都来自哪里吧？还记得那本书《JavaScript: The Good Parts》吗？从那以后，人们开始用“好的部分”来形容很多东西。就像“Johnny，好的部分。”这是什么意思？

Ian Lopshire：还有《The Hard Way》（困难之路）。

Johnny Boursiquot：对，还有“困难之路”。

Kris Brandow：但我觉得《JavaScript: The Good Parts》也和《JavaScript: The Definitive Guide》（JavaScript权威指南）形成了对比。《权威指南》有1000多页，而《The Good Parts》只有150页左右。

Johnny Boursiquot：对，没错。这种对比非常有趣。你必须是在出版行业里的人，才能明白其中的笑点。

Kris Brandow：是的。

Johnny Boursiquot：我想象是这样。不管怎样，Redka。你对此感觉如何？

Ian Lopshire：我对这些新东西很感兴趣，尤其是那些使用 SQLite 的新项目……我知道 SQLite 一直被广泛使用，也很受欢迎。但我感觉在过去的一年里，我听到关于 SQLite 的消息越来越多了。

Johnny Boursiquot：它火了。我同意……对我个人来说，你知道是什么让它变得对我的生活更加重要吗？就是——

Kris Brandow：哦，是 Ben Johnson 吗？

Johnny Boursiquot：没错，就是 Ben Johnson。他创建了 BoltDB，我用了很长时间……他对数据库和数据库服务器的开发非常有见解。他有一个项目，我记得叫 Litestream，基本上是在你的使用场景合适的情况下，你可以把 SQLite 用于生产环境，实际上可以拥有一个可靠的系统，能够持续进行流式备份，而且不会丢失数据……他让我意识到，SQLite 不仅仅是一个玩具数据库，或者仅用于本地开发，或低功耗设备等，它实际上可以替代我们常用的数据库，比如 Postgres、MySQL 等等。

所以我同意，在某些使用场景下，SQLite 非常有能力。对我来说，主要的问题一直是写入锁的问题，因为它每次只能进行一次写入……在某些情况下，你需要聪明地规避这个问题。也许你只有一个写入者，但是有很多读者……但你必须在设计你的软件架构时，采用有别于使用完整数据库（如 Postgres 或 MySQL）时的方式，进行一些额外的思考。

Kris Brandow：我想也是……虽然当你使用 SQLite 时，它的速度比 Postgres 或 MySQL 快很多个数量级……因为你没有网络连接。你就在本地执行操作，所以总体上要快得多……不过我也认为，你确实需要以不同的方式构建系统，但如果你想把 SQLite 放在应用程序的核心位置，那么你还需要从宏观上重新构建你的应用程序。

Ian Lopshire：我看到一些文章提到，有人每个用户都使用一个独立的 SQLite 数据库。

Johnny Boursiquot：是的，类似这种……当你开始从不同的角度思考问题时……它只是一种磁盘上的文件。为什么不为每个用户提供一个文件，当他们登录时，他们就有自己的数据库？这有点让人难以适应。如果你习惯了传统的框架服务器连接数据库的方式，比如 RDS、关系数据库、连接池等等……虽然有点不习惯，但想想也没什么为什么不行呢？为什么不能给每个用户一个独立的数据库呢？

Kris Brandow：我觉得 SQLite 也很有趣，因为它基本上是一种非常稳定、非常可靠的文件格式。美国国会图书馆甚至把它列为可以保存几个世纪的数据文件格式之一。我想它是唯一的二进制文件格式。其他的都是文本格式，比如 CSV 和 JSON。但 SQLite 也在其中，而且它是一个完整的系统。我还会极力主张使用 SQLite 作为应用程序的存储格式，这也是为什么它可能是世界上最流行、使用最广泛的数据库。

Ian Lopshire：我想很多 Apple 应用都内置了一个 SQLite 数据库，对吧？

Kris Brandow：是的。而且每个浏览器也都有。

Johnny Boursiquot：是的，我想大多数东西都带有 SQLite。

Kris Brandow：如果你在使用某个应用程序，你会想“它的数据存在哪里？”大概率是存在 SQLite 数据库里。应该就是那里。

Johnny Boursiquot：大概就是 SQLite，没错。

Ian Lopshire：我也觉得它和 Redis 很契合，因为 Redis 本身就是单线程的。它是一个请求队列。所以写入锁好像并不是个大问题。

Kris Brandow：是的，我觉得它确实非常适合这种使用场景。即使你想做一个分布式的 Redis，我想已经有人做过几次这种尝试，他们在 Redis 上加了 Raft 协议……我记得它叫 RQLite，或者类似的东西……通过 Raft 把它分布化，你可以对 Redis 做同样的事情，把 Raft 放在 Redis 和 SQLite 之上，你基本上可以实现同样的效果。

Ian Lopshire：它还自带了 Go 客户端……我觉得如果你是在同一台机器上运行，甚至都不需要使用网络协议。

Johnny Boursiquot：这确实很酷。现在我对重新评估 SQLite 在我生活中的选择产生了兴趣。

Ian Lopshire：在我们讨论的时候，我已经给它加了一个 Star……

Johnny Boursiquot：是的，没错。它才上线一个月……[笑] 我是说，别急着在生产环境中部署它。

它的第一次提交是一个月前，所以大家要小心。我感觉 SQLite 在 Go 社区里也有点复兴的味道，因为我记得有个人，他基本上在努力开发一个纯 Go 实现的 SQLite，这样你就不用使用 cgo……而且我想它最近刚刚发布 1.0 稳定版，或者达到了一个非常稳定的阶段，所以你现在可以更放心地使用它，而且它基本上是 SQLite 的直接替代品，这意味着如果你想在 Go 中使用 SQLite，你不必依赖 cgo，我觉得这是一个巨大的优势，真的开拓了很多机会。

本来把 SQLite 嵌入 Go 中已经很简单了，因为它是打包成一个单独的 C 文件发布的，没有任何依赖……所以从 C 语言集成到 Go 中来说，已经算是比较简单的了……但能够轻松地进行跨编译，确实是一个巨大的优势。

Johnny Boursiquot：我们应该做一期关于许可证的节目，因为每当我看到许可证时……我唯一知道的是 MIT 许可证好，其他的都存疑，对吧？[笑声] 如果我看到 BSD 3-Clause 之类的东西……我就得去做点研究，看看我能不能用这个东西。

Kris Brandow：我是说，BSD 和 MIT 是两种许可, 它们的态度基本上是一样的。

Johnny Boursiquot：是的，我觉得我们应该做一期关于许可证的节目。

Kris Brandow：是的。我们可以请 Luis Villa 再来一次，因为他是个律师。我们之前和他谈过其他知识产权方面的事情。和他谈谈许可证问题会很有趣。

Ian Lopshire：如果他参加节目，你一定要听。这些是我们做过的最好的节目之一，我认为。Johnny 你在第 300 集的时候也说过这一点，所以……在 Johnny 非常喜欢的 “This is Sparta” 那一集，尽管那已经是 20 年前的电影了……[笑声]

Johnny Boursiquot：那还有什么？我们还有新闻要说吗，还是……

Kris Brandow：我是说，还有一些新闻我们可以讨论，如果你们想聊的话……或者我们可以来一轮快速的“不受欢迎的意见”。让我们开始吧，我还有事要干。[笑声]

Kris Brandow：那么，进入“不受欢迎的意见”环节。

Kris Brandow：好了，Johnny，你有什么不受欢迎的意见吗？

Johnny Boursiquot：fork Redis……如果你还没这么做的话。

Kris Brandow：这听起来像是非常受欢迎的意见，先生……

Johnny Boursiquot：[笑] 哦，天哪……我自己玩得太开心了。

Kris Brandow：好吧……

Johnny Boursiquot：是的，就是这样。

Kris Brandow：好吧，分叉 Redis。不受欢迎的意见。好的。Ian——

Johnny Boursiquot：如果你还没这么做的话，赶紧去做。

Ian Lopshire：我觉得“分叉 Redis”不是一个意见。“你应该分叉 Redis”才是一个意见。[笑声]

Kris Brandow：Ian，你在我们这里真是如鱼得水，这么吹毛求疵。好吧……

Ian Lopshire：我其实有一个不受欢迎的意见。

Kris Brandow：好吧，说吧。

Ian Lopshire：我一直觉得那些高级办公椅很傻，像 Herman Miller 之类的昂贵办公椅……我用了两年半的椅子是专门为餐桌设计的。(译者注: 看来HHKB和Herman Miller 也不分国界)

Kris Brandow：这对你的背部一定很糟糕，但继续。

Johnny Boursiquot：Ian，老兄，你在干什么……？！

Ian Lopshire：嗯，我的背确实有点疼。也许我该看看新椅子。

Johnny Boursiquot：[笑] 你觉得呢……？

Ian Lopshire：所以我终于买了一把办公椅，Herman Miller Embody，真是改变生活的体验。每个人现在都应该去买一把。我的背不疼了……我应该十年前就这么做。所以我的意见是，贵的椅子并不被高估。[笑声]

Johnny Boursiquot：这就像你从 Notepad 转到一个真正的代码编辑器一样。很长一段时间你会觉得“那些用高级语法高亮、错误提示的家伙在干什么？这些花哨的东西有什么用？我喜欢 Notepad，它很好用。”

Kris Brandow：就像“1000 美元的办公椅？我宁愿付钱做背部手术。”

Johnny Boursiquot：哦，天哪……

Ian Lopshire：不过我买得便宜，所以不用担心……

Johnny Boursiquot：Ian，老兄，老兄……哇。哇。好吧。

Ian Lopshire：我还以为自己只是老了，结果是我每天坐在一把坏椅子上坐了十个小时。

Johnny Boursiquot：你已经用了 Notepad 版的椅子十年了。[笑]

Kris Brandow：Notepad 版的椅子……我意思是，当你第一次使用一个 IDE 或者一个好的编辑器时——是的，就像“哦，好吧……”至少升级到 Notepad++ 吧。你怎么能一直用 Notepad 呢？

Johnny Boursiquot：不过，不是只有 Windows 上有 Notepad++ 吗？我知道这个是因为我用了好几年，不得不说。那时候它是很棒的。

Kris Brandow：Notepad++？

Johnny Boursiquot：是的，因为它支持——是的，它很好用，因为我可以有不同的语言语法文件，还有其他东西……真的很棒。

Ian Lopshire：我很长一段时间都是 Sublime Text 的用户。

Johnny Boursiquot：最终，我们都——我是说，我们不都是吗？它是新一代编辑器的开创者……

Kris Brandow：我从来没用过 Sublime。不过那是因为我直接从糟糕的基于 Eclipse 的 IDE 跳到了 Vim，然后我就一直留在那里了。

Johnny Boursiquot：哦，你真是走了两个极端。从 Eclipse 这种笨重的工具，直接跳到 Vim 这种纯文本编辑器。

Kris Brandow：是的，我当时是用的 Eclipse 的一个衍生版，用来写 PHP，然后我觉得“这东西启动太慢了，所以我开始用——不是 BBEdit，而是另外一个……哦，TextWrangler。我用 TextWrangler 做了一些事情，然后……我觉得我应该学会使用一个更好的编辑器。因为我经常在服务器上工作……”所以我想“我要学 Vim 还是 Emacs？” 最后我决定学 Vim，因为它几乎是每个系统的默认编辑器，所以我就学了 Vim。

Ian Lopshire：但是你能退出吗？

Johnny Boursiquot：你能退出它吗？Kris 可能还在使用他 20 年前打开的会话……[笑] 还没弄清楚怎么退出……

Kris Brandow：就像，“我该怎么退出？冒号什么？:q，但我有一个修改过的缓冲区。我该怎么办……？！”

Johnny Boursiquot：[笑] 哦，天哪……

Ian Lopshire：我记得我第一次尝试做交互式 rebase，结果直接把那个分支给删了。[笑声]

Kris Brandow：其实退出 Vim 并没有那么难。

Ian Lopshire：如果你不知道自己在 Vim 里，那就很难……[笑声]

Johnny Boursiquot：哦，天哪……你们今天带来了很多笑话。

Kris Brandow：我是说，我有 Vim 的海报。必须得代表一下。

Johnny Boursiquot：这就是你知道的方式。你的海报上有退出的快捷键吗？

Kris Brandow：嗯，没有。

Johnny Boursiquot：……在你的海报上……[笑]

Kris Brandow：如果有人在听，是:q。如果你想保存并退出，不要傻傻地多敲一个按键用:wq，直接用:x。更高效。

Ian Lopshire：我不知道这个。我还一直用:wq。

Kris Brandow：是的，:x 和:wq 做的是同样的事情。

Ian Lopshire：Kris，你有不受欢迎的意见吗？

Kris Brandow：Vim 是世界上最好的文本编辑器……我说了什么来着？不，哈哈。让我想想……不受欢迎的意见。我有吗？我意思是，“我有的是不是我想说出来的？”才是真正的问题。我可能之前说过这个，但既然我们在谈编辑器，去学一下 Vim 或 Emacs。去学一个不错的基于终端的编辑器。至少尝试一段时间，因为我觉得你的生产力会飞速提升……不像使用 IDE 那样。不是说我对 IDE 有意见。

Johnny Boursiquot：我得不同意你的那个列表。Emacs 不仅仅是个编辑器，它是一种生活方式。

Kris Brandow：我是说，Vim 也是一种生活方式…… (译者注: 开始圣战…)

Johnny Boursiquot：所以你不会“只是”使用 Emacs。它是一种生活方式。所以如果你想试试一些编辑器，你不会“仅仅”试试 Emacs。这是一种投资。你得慢慢入门，学习它的方式，最好找个大师来教你，成为一个学徒，找个绝地大师来帮助你。

Kris Brandow：如果你以前弹过钢琴，那 Emacs 就适合你。

Johnny Boursiquot：[笑]

Ian Lopshire：把你的键盘布局换成 Dvorak，然后……

Johnny Boursiquot：[笑]

Ian Lopshire：是这样发音吗，Dvorak？我也不知道。

Kris Brandow：我也不知道。但你知道，Emacs——如果你喜欢 Lisp，Emacs 对 Lisp 非常友好。幸运的是，Neovim 现在有了 Lua……还有 Go。你现在可以用 Go 为 Neovim 写插件，这真的很酷。我最近也在尝试。但我想说，我的不受欢迎的意见是，学一学基于终端的编辑器……这并不适合所有人。这不像 IntelliJ 或 JetBrains 的其他IDE，那种打开就能直接使用的体验。你需要进行一些配置，构建你想要的东西。但如果你搞清楚了怎么做，这会是非常不错的体验。

我喜欢不需要将手从键盘上移开就能完成大部分写作的感觉。所以……试试吧。这就是我想说的。每个人都应该试试看。如果不适合你，那就不适合你。我们都喜欢一点自我探索，一点自我旅程……或者像 Johnny 所说的，人生漫长的篇章，去弄明白 Emacs 是怎么工作的。

Johnny Boursiquot：[笑]

Kris Brandow：我是说，你说得没错，Emacs 的 Org mode… 我的一些朋友一直告诉我说：“你应该用 Org mode，这是一种很好的生活组织方式。”我明白了，大家真的很喜欢 Emacs。人们几乎在 Emacs 里生活。他们会把整个人生都放在 Emacs 上。我是说，几乎是字面上的意思。[笑声] 他们把所有的任务、日历、待办事项都放在里面… 我敢肯定还有查看电子邮件的方法… 你几乎可以在里面做任何事情。

Johnny Boursiquot：这就是我说的，这是一种生活方式。这是一种生活方式。

Kris Brandow：对啊，可能这种生活方式适合你，那就去试试看吧。

Johnny Boursiquot：不不… 我还是喜欢用日历，我就这样挺好的。

Kris Brandow：我是说，我讨厌日历。这是另一个完全不同的话题。

Johnny Boursiquot：对，我们还是别开始这个话题了。[笑声]

Kris Brandow：我们应该做一个额外的节目，叫“Kris有多讨厌日历？” 不管怎样… 这听起来像是我们结束的好地方。

Johnny Boursiquot：克里斯会随机出现在不同的日子和时间参加会议。这就是他有多讨厌日历。

Kris Brandow：我勉强用日历。别让我开始这个话题。

Johnny Boursiquot：停停停…!

Kris Brandow：除非我们想做一个特别加长版的节目，让你来谈谈日历…

Johnny Boursiquot：不不… 停，停。[笑声] 紧急，紧急。

Kris Brandow：看吧，Johnny，别太调侃我，因为你不知道会发生什么。我可能会对着日历说上半个小时。好了… 这期节目很有趣，聊了一些新闻和那些有趣的东西… 但没错

Johnny Boursiquot：对，我们应该更经常这样做。

Kris Brandow：对啊，听众们，如果你们喜欢我们聊新闻… 虽然这次也有点像是元新闻加新闻。但你知道的，Johnny 一上节目，肯定会变得有点“元”。不过如果你喜欢这种新闻话题，并且希望我们做更多新闻报道，告诉我们吧。可以通过各种平台联系我们，比如 Gopher Slack 或 Changelog Slack… 如果你还没加入 Changelog Slack，赶紧加入吧… 是的，如果你喜欢这种形式，告诉我们，我们会安排更多。

在此，感谢 Johnny 的加入。很高兴有你在。

Johnny Boursiquot：还有 Ian。你忘了 Ian 吗？[笑声]

Kris Brandow：我本来是想等你说的

Ian Lopshire：我还以为我们是朋友，Kris。我还以为我们是朋友。

Kris Brandow：谢谢你在这里，然后我本来是要说“谢谢 Ian 也在这里。”我是在倒着做结束语。像我开头那样倒着来。下次我会把你放在最后。我会说“谢谢你加入我，Johnny。”然后你会说“哦，谢谢邀请我。” 然后我会说“也谢谢你，Ian。” 然后你会说“谢谢邀请我。” 然后我们就可以说“好，结束了。” 但我们不能这样做，因为你非得挑剔一番。我不会对我的朋友这样。Ian 是我的朋友。对你来说这很粗鲁，Johnny。

Johnny Boursiquot：[笑声]

Kris Brandow：很高兴你们两个都在，Ian 和 Johnny…

Ian Lopshire：很高兴能在这里，Kris。

Johnny Boursiquot：是啊，Ian 也在。[笑声]

Kris Brandow：哦，天哪… 也感谢你，听众们，感谢你们坚持听完这一整集节目。我们下次 Go Time 见。

• Go