Performance, fuzzing & magic

本篇内容是根据2018年1月份Performance, fuzzing & magic^[1]音频录制内容的整理与翻译,

[Damian Gryski]((https://github.com/dgryski "Damian Gryski")) 加入了节目，并与我们讨论了性能手册、性能分析、阅读白皮书的乐趣、模糊测试以及其他有趣的项目和新闻。

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

Erik St. Martin: 欢迎大家回到 GoTime 的另一期节目。这是第 66 期节目。今天在节目中有我，Erik St. Martin^[2]，还有 Carlisia Pinto^[3]...

Carlisia Thompson: 大家好。

Erik St. Martin: 还有 Brian Ketelsen^[4]...

Brian Ketelsen: 大家好！

Erik St. Martin: 今天我们的特别嘉宾，我非常激动地介绍，他是 Damian Gryski。大多数人可能认识他，因为他总是在谈论白皮书，而我个人其实希望能读懂那些白皮书... 在我们进入性能优化和模糊测试之前，你能否为那些可能还不太熟悉你的人简单介绍一下你自己？

Damian Gryski: 好的，我叫 Damian，我从 Go 1.0 之前就开始使用 Go 了。我还记得像 os.Error 这样的东西。我在 Twitter 上经常发关于 Go 的内容，我是 Go SubReddit^[5] 的版主，那里我也经常发布内容。我喜欢计算机科学研究类的东西，所以我有很多存储白皮书和实现的仓库。我曾在阿姆斯特丹为 Booking.com 工作，现在我在温哥华为 Fastly^[6] 工作。这就是我的简短介绍。

Brian Ketelsen: 我们认识在 Fastly 工作的其他人吗？

Erik St. Martin: 好像有...

Carlisia Thompson: 没有吧...

Brian Ketelsen: 我好像应该认识一个人，但一下子想不起来了... 感觉我应该认识在 Fastly 工作的人。

Erik St. Martin: 在开始节目之前，我们聊到你曾经做街头表演和魔术... 我觉得这个很有意思，因为你后来决定学习计算机科学，而且学得很深入；你决定去阅读和实现论文，甚至写论文... 这真的很酷。

Damian Gryski: 是的，我小时候---我其实和我的女儿以及岳父母讨论过这个话题... 我们都在说“你长大后想做什么？”我意识到，虽然有一段时间我和杂耍艺人和魔术师在一起，想着“也许这是一个很酷的职业”（因为我当时才 12 岁），但我其实很早就开始编程了。我保留着五六年级时的一些数学和编程书籍... 所以其实我一直都很迷数学、计算机和编程。所以这不是完全的转行，而是我意识到“哦，原来这才是更适合我的职业道路”。

Erik St. Martin: 所以你只是把爱好和职业换了个位置。

Damian Gryski: 是的。

Erik St. Martin: 太棒了。最近你谈论了很多关于性能优化的内容。我们来聊聊性能优化的时机和原因吧，像 Go 这样本来就很快的语言，什么时候和为什么需要关注性能优化？

Damian Gryski:  好的，我先简单介绍一下我正在写的这本性能优化书。我主要待在 Gophers Slack 的 performance 频道^[7]，我当时的想法是，我们有这么多关于如何优化 Go 的知识，应该把这些博客文章收集起来，做成一个资源，从少数人的头脑中提取出来，变成更容易分享的东西。

所以我收集了很多资源，开始写一些关于优化和性能工作的个人想法；有时我会往里面添加一些内容。今年年初，我在查看我的代码库时，注意到“哦，我有这么一个 性能优化书项目^[8]。”它有点停滞了... 于是我发了几条有点自嘲的推文---显然，这个项目没有火起来的原因是因为它没有被命名为“Awesome GoLang Performance！”，所以没有上 Hacker News 的首页... 那条推文得到了很多转发，我在 24 小时内收到了 200 个 stars。我想，“哇，原来这个项目其实是有人关心的。”

因为要从阿姆斯特丹搬到温哥华，我暂时终止了我的 GitHub streak（连续提交记录），给自己更多的时间。现在我在想“也许我会在 2018 年里花时间完成这本性能优化书。”所以这就是我大部分空闲时间的去向。我目前写了大约 5,000 字，但还没有真正涉及 Go 特有的优化技巧... 目前都是关于性能和优化的通用想法，这些内容适用于任何你想加速的项目。所以这是这本性能优化书的历史...

Carlisia Thompson: 你对性能的看法是来自你自己的探索和实验，还是源于之前生产环境中的实际经验？我问这个是因为我在想，人们为什么会有动力去探索不同的性能测量方法？还是说这其实没有那么重要？也许他们只需要读一本书，或者查阅现有的资源？人们应该如何开始这个过程？为了回答这个问题，我想先了解你是如何进入这个领域的。

Damian Gryski: 我喜欢做的一件事就是阅读计算机科学研究，而大多数研究都是“这里有一个更好的算法来做这件事”，至于如何衡量“更好”，则各有不同---有时是速度更快，有时是精度更高，有时是内存占用更少... 问题在于如何应用这些研究，如何判断它们不仅在理论上有用，还在实际生产中有用。所以我对性能的兴趣主要来自于想要把计算机科学研究应用到实际中。

至于谁应该关注性能优化---这取决于你在技术栈中的位置。如果你在构建基础设施，那么性能可能会显得更加重要，因为有些事情是以你为基础的，你希望自己尽可能快，因为在上层，他们的速度不能比你快，如果你很慢，那就限制了他们的速度。

但如果你做的是纯粹面向客户的产品，或者是其他类型的基础设施，可能你不太关心性能，因为你的目标是快速发布产品。比如，你的目标是改善可用性，或者增加新功能，而不是性能。这样的话，性能就不应该是你的首要考虑。

Brian Ketelsen: 你觉得有多少 Go 开发者需要关心性能？

Damian Gryski: 这要看情况了。对许多人来说，从解释型语言（如 Perl、Python，甚至是很快的 Node.js）转到 Go，性能上的提升已经足够了。虽然 Go 比 C 慢两倍，但相比 Perl 或 Python 这样的语言，它们可能比 C 慢 30 倍，而 Go 比它们快 10 到 15 倍。所以对于大部分人来说，转换到 Go 就足够了。只有在需要更智能地处理问题时，才需要关注性能。

在 Booking.com 这样的公司，我的经验是，开发者人数众多，代码库庞大... 有多少人关注性能？有多少人需要关注性能？这取决于软件的用途，以及它是否已经足够快、占用合理的内存。对于大多数人来说，答案是“是的，已经足够好了。”

只有少数人真正需要全力关注性能，去挖掘最后的 10%、20%，甚至 1%、2%，进行深入优化。其他情况只需要遵循我在性能书中提到的简单原则：选择合适的数据结构。不要做蠢事。

如果你主要是基于键的查找，使用 map。如果你需要顺序访问，使用 slice。为你的数据访问模式选择合理的数据结构。然后，如果你发现程序不够快，比如说一个小时的报告需要一个半小时才能生成，那么显然这不够快。又或者你发现内存不够了，那么就需要进一步优化数据结构和压缩数据。

Erik St. Martin: 我期待看到推特上的新名言：“别做蠢事。”

Erik St. Martin: 我忘记是从哪里听到的了，但有人说在分析性能时，要“专注于最大的块，然后每次你缩小一个块时，接着专注于下一个最大的块。”

Damian Gryski: 是的，因为那些基本上就是瓶颈，对吧？这意味着“这是程序花费时间的地方”。所以你要么想让那个慢的部分变得更快，通过选择不同的算法，而不是仅仅调整代码和切换一些东西……或者从更大的层面上，你可以说：“为什么那个块必须存在？也许我可以做些事情来减少它被调用的次数。”

所以你的程序要么是在做一些不太慢的事情很多次，要么是在做一些慢的事情。因此，你要么想让那个慢的部分变得更快，要么减少执行那个慢的事情的频率。加速程序基本上只有这两种方法。

Erik St. Martin: 是的，cgo 就是一个典型的例子，它是那种昂贵的调用。所以，如果你减少调用 C 的次数，你可以使 cgo 调用变得更加高效。

Damian Gryski: 这就是批处理派上用场的地方。我不想每次都调用 cgo 来做这件事，所以我会创建一个包含一百个元素的数组，然后一次性传递给 cgo，这样我只跨越一次边界。

Carlisia Thompson: 在你的书里，你会列出类似的策略吗？比如，如何处理甚至避免性能问题的策略？

Damian Gryski: 会的……正如我之前提到的，我目前的目标是把我对性能优化的所有知识以及一些通用的策略都写下来，然后再深入到 Go 语言的具体内容，比如如何使用 pprof 和不同的性能分析工具，如何编写基准测试，如何阅读 pprof 的输出，以便知道哪里需要优化……还有处理器级别的优化，比如缓存行、内存填充、并发访问---如果你有很多 goroutine，如何加速访问相同的数据结构，或者分支预测……这些都是比较低级别的内容。我还打算讨论垃圾回收，如何最小化内存分配，逃逸分析等等。其他在性能分析时会出现的问题，比如运行时调用、接口转换、类型断言、边界检查消除等。

我还会涉及到 unsafe。虽然 unsafe 是不安全的，但它也可以带来速度上的提升……还有一些 cgo 的内容，以及汇编，因为有时使用汇编确实能提高性能，但并不是总是如此。我遇到过用汇编写的代码性能提升了 10 倍的情况，也遇到过性能没有提升的情况，写出来的代码实际上和 Go 编译器生成的代码是一样的。我还遇到过汇编实现反而更慢的情况，因为汇编函数不能被内联……所以我会讨论所有这些内容。目前，我已经完成了大部分关于性能优化的内容，也为 Go 语言的特定部分做了纲要……不过，现在才一月，所以我还有很多时间。

Brian Ketelsen:  这一年还很长。

Erik St. Martin: 你打算在年底前完成它吗？

Damian Gryski: 我不确定。这是我的业余项目，看看会发生什么吧。

Brian Ketelsen: 我希望你能在我下次教授 Go 性能优化课程之前完成……顺便提醒一下。

Carlisia Thompson: 是下个月吗？

Brian Ketelsen: 我不确定……可能很快吧。

Damian Gryski: 第一个章节几乎完成了。我的通用性能优化思路已经差不多了。也许还需要编辑一下……但具体到 Go 的部分还需要更多的写作工作，我觉得那些部分会更容易些，因为这不仅仅是我的个人意见。比如，“如何使用 unsafe？”有一种显而易见的方法可以使用 unsafe 来做这些事情，所以这些部分更像是教程。我认为一些后面的章节会更像是教程部分，这些会更容易写，因为你只需要写出你想要讨论的内容。

第一部分关于何时优化以及更高层次的优化策略花了我比较多的时间，因为我编程的时间很长了，我也阅读了很多关于软件工程和性能优化的内容，并且做了很多这方面的工作，结果发现我有很多话要说。直到我开始写下来，我才意识到这一点。

Brian Ketelsen: [笑] 你享受写作的过程吗？

Damian Gryski: 是的，其实挺享受的。把所有的想法从脑海中倾泻出来感觉很好，还能想起“哦对，这也是一个有趣的点”。而且我经常在性能频道和别人讨论这些内容，所以很高兴能告诉大家“去这里看看我的观点”。

Erik St. Martin: 是的，我们应该提一下，在 Gopher Slack 上有一个性能频道。

Damian Gryski: 大多数时候你可以在那里找到我。

Erik St. Martin: 还有一个问题……你刚才提到要根据访问模式选择合适的数据结构和算法……如果你有很丰富的知识，这点当然很好。那么你会如何建议大家熟悉更多的数据结构和算法，以便在需要时有更多选择？或者你建议大家先用语言提供的标准工具，然后再寻找更高效的数据结构？

Damian Gryski: 我认为实际上大多数人日常只需要使用少量的数据结构，幸运的是，它们已经内置在 Go 语言中了。比如，你需要一个 slice，因为你想要常数时间的 append 操作，并且需要随机访问，或者你需要按照顺序迭代数据。或者你需要一个 map，因为你需要某种键值对查找。这些已经覆盖了大多数开发者的需求，而这也是它们被内置在语言中的原因。

某些生僻的数据结构有非常特定的用例，你不需要知道如何实现它们，但知道它们的存在是有帮助的。我是怎么学会的？嗯，我的背景是计算机科学学位，而且是一个理论倾向很强的大学，所以我翻开了书本，做了所有的工作。每个人都需要这样做吗？不，可能不需要。

如何学习更多的数据结构？挑一个你感兴趣的，但我认为大多数开发者需要掌握的数据结构数量其实很少。了解二叉搜索树是怎么工作的很好，了解 AVL 树或红黑树的性能保证和普通二叉搜索树的区别也很好……但如果让我实现这些，我不会选择 AVL 树或红黑树，因为它们的实现非常麻烦，真的很烦……而 treap 可以提供基本相同的性能，却更容易实现。所以如果我需要一个 slice 或 map 解决不了的问题，并且需要一个具有对数级别性能和有序保证的树结构，我会选择 treap，因为它更简单。但你需要了解现有数据结构的局限性。市面上有很多数据结构，挑些主要的去学习。

Erik St. Martin: 那你认为有哪些数据结构是大家应该知道的？或者说你最喜欢的有哪些，可以推荐给大家？

Damian Gryski: 我觉得堆是非常实用的，因为经常会遇到类似的场景。布隆过滤器（Bloom filters）我觉得非常酷。

Erik St. Martin: 哦，是的……

Damian Gryski: 特别是在做性能优化时，布隆过滤器能快速判断“我是否需要做这件事？是否需要执行这额外的工作？”布隆过滤器非常酷，而且作为很多系统的组件经常出现。比如，我实现了一个叫 TinyLFU 的缓存淘汰算法，其中有一个小型布隆过滤器，它基本上会判断“我之前是否见过这个数据？如果见过，可能还会再次见到，所以把它加入缓存。但如果之前没见过，就暂时不要加入缓存，因为它可能是一次性的。”布隆过滤器本身很酷，但作为其他系统的组件时更酷。

我谈论数据结构时，往往更偏向我个人的兴趣。比如 Count-min sketches（计数最小草图）---有很多概率性的东西，它们很酷，因为它们简单但有效，融入了随机性。再回到 treap---它们也很酷且容易实现……你可以看看我的 GitHub。

Brian Ketelsen:  我正想说，如果你想看一些有趣的内容，去 Damian 的 GitHub 页面吧，那里有很多技术论文的精彩实现。他每隔两分钟就在 Twitter 上宣布发现了一篇新论文，然后用 Go 实现了它，给大家分享。

Erik St. Martin: 这就是你的口号，“我帮你实现白皮书，这样你就不用动手了。”

Brian Ketelsen: 确实应该是。

Erik St. Martin: 我特别喜欢这种事情，比如 Raft 出现的时候……我喜欢人们把这些复杂的东西简化为易于理解的内容。像 Raft 论文才 11 页？这比其他分布式共识算法简单多了。

Brian Ketelsen: Paxos……

Damian Gryski: 我尝试读过 Paxos 论文---它很有趣，但也很难懂……我觉得它的设置很有意思：整个“兼职议会”的设定是“我们发现了这个爱琴海小岛上的历史议会系统是这样运行的”。最后才说“顺便说一句，这对计算机系统也适用。”但整篇论文特别难懂。你可以试着去读……我读过了。很高兴 Raft 出现了，因为我能理解；虽然我也明白 Paxos 的工作原理，但不是通过读 Paxos 论文学到的。

Erik St. Martin: 是的，而且好像有很多 Paxos 的实现版本，每个版本都不一样。每个人对它的理解都不同。

Brian Ketelsen: 我记得读到过某位 Paxos 专家说，除了 Google 之外，他还没见过一个正确的 Paxos 实现。这我一点也不惊讶。

Damian Gryski: 我完全相信这一点。还有一件有趣的事情，特别是在谈论 Paxos 时，就是 Google 发布的关于 Chubby^[9] 的论文，Chubby 基本上是他们实现 Paxos 的一种方式……我猜这也是 Zookeeper^[10] 的实现方式，不管怎样；Zookeeper 基于 Chubby，而 Chubby 实现了 Paxos，等等……在谈论如何在 Paxos 论文中的算法只是构建一个可以称之为服务的系统所需的一个非常小的部分，而且还有很多其他奇怪的边缘情况在 Paxos 中没有被覆盖，你需要从其他论文中找到这些零零碎碎的东西来填补空白……但这足够了吗？我不知道。

我认为 Chubby 论文从软件工程的角度来看非常有趣，它真正尝试将理论付诸实践，虽然这些东西有证明与之相关，但研究人员以及这些论文背后的工作实际上只是其中的极小一部分，而要把所有东西结合起来构建一个可以实际部署的系统，则需要额外的很多工作。

Erik St. Martin: 是的，即使你看看 Raft---Raft 本身解释了共识算法如何工作，但当你实现它，比如 etcd^[11] 或 Consul^[12] 这样的东西时，还有很多其他的工作要做……特别是当你谈论一个能够经受时间考验的服务；你需要能够备份数据并压缩日志等等。这比仅仅共识算法要复杂得多；这只是个核心部分，正如你所说，还有更多的工程问题需要解决。

说到性能，另一个你非常感兴趣的话题是模糊测试。对于可能不熟悉模糊测试的人，你能否给大家简单介绍一下什么是模糊测试，然后我们可以讨论为什么你认为每个人都应该做模糊测试？

Damian Gryski: 模糊测试本质上是随机测试。如果你有一个程序接受用户输入---也许是通过网络，也许是文件---模糊测试基本上是在问：“你忘记了哪些边界情况？” 模糊测试总体上是这样，然后还有 go-fuzz^[13] 包，它让 Go 的模糊测试变得简单。但模糊测试总体上是生成随机输入并将其扔给你的程序，然后看看会发生什么。假设是你的程序不应该崩溃。如果程序崩溃了，那就找到了一个 bug。

Go-fuzz 是一个为 Go 设计的工具，它让这变得非常简单---你写一个简单的 fuzz 函数，它会生成数据并调用这个 fuzz 函数。Go-fuzz 使用的是所谓的覆盖引导模糊测试……它会查看特定输入在你的代码库中覆盖了多少，然后如果该输入探索了更多的情况---基本上，它获得了好的覆盖率并进入了之前输入没有进入的路径，那么它会说：“哦，这是更有趣的输入，所以我要保留这个，并改变这个输入的位，看看是否可以获得更多的覆盖率。”

所以覆盖引导模糊测试让我们能够很容易地缩小范围，基本上找到你没想到的边界情况。我非常喜欢随机测试。测试本身就很好，随机测试更好，而我认为 Go-fuzz 基本上能够发现我扔给它的几乎所有东西中的崩溃点。所以你找到一个存储库，然后你问：“你检查了所有的边界情况吗？” 答案几乎总是没有，而 Go-fuzz 会为你找到它们，通常非常快。

Brian Ketelsen: 如果它还能生成修复程序，那就更好了。

Damian Gryski: 你应该读一下 DARPA 网络挑战赛^[14]……

Erik St. Martin: 哦，好的。

Damian Gryski: 那些东西真是太棒了。这些是完全---我可能会说错，但基本上是完全自动化的系统，它们必须同时检测代码中的攻击并修补它们……基本上是自动生成这些程序的修补程序，我认为可能还有一个攻击组件，但我不确定。不过，真的，去搜索一下 DARPA 网络挑战赛（我想是这个名字），看看---我知道有一个 YouTube 视频^[15]，我看过，是对整个事情的一个总结。那里进行的一些工作真是令人惊叹。

Brian Ketelsen: 听起来是个消磨一天的好方式。

Erik St. Martin: 今年在纽约 Velocity 大会上也有一个演讲，提到一些大学和团队合作，他们使用了 AI/ML 组件来猜测最合理的代码修改是什么，以使其正确。我得想起那个演讲的名字，如果我想起来，我会确保它出现在节目笔记中，但也是类似的思路，我们可以将这些东西输入系统，只有一些正常的程序员可能会对某些东西进行的修改，然后它可以做出一个不错的猜测。最终，我们可能不再需要工作了……有人会写一个编写代码的 AI 系统，他们会非常富有。

模糊测试不仅对稳定性有好处，对安全性也有好处，因为通常，如果你能让一个程序崩溃，你就能控制它。即使最坏的情况下，你也可以对它进行拒绝服务攻击。

Damian Gryski: 对于 Go 来说，这个问题不太严重，因为它有内存安全性，但如果你用 C 或 C++ 写服务器，那么，崩溃通常也意味着它是可利用的漏洞。

你还可以用 Go-fuzz 进行另一种测试，不是为了寻找崩溃，而是比较两个实现。所以我有一个慢速实现和一个快速实现，我会使用覆盖引导模糊测试，确保我探索了慢速实现和快速实现的所有角落，然后我会比较它们的输出。如果输出不一样，我就会让它崩溃。

然后 Go-fuzz 找到崩溃点，这意味着“我找到了一个慢速实现和快速实现输出不同的情况。”

Brian Ketelsen: 这很酷。

Damian Gryski: 模糊测试有很多用途，不仅限于传统的漏洞检测。

Erik St. Martin: 我找到了……它叫“FTFY: 自动修复漏洞的研究进展。” 来自卡内基梅隆大学的一些人……我会把链接放在那里。好的，我们看看时间如何？

Brian Ketelsen: 嗯，可能是时候转到新闻了……

Erik St. Martin: 我觉得是的。首先，1.9.3 几天前发布了，所以现在就更新吧……提交 bug 报告，因为我们知道你们在测试版期间根本没测试……[笑]

Brian Ketelsen: 这一版其实没什么大变化。我看了一下 GitHub 上的问题，内容挺少的；没什么大问题。

Erik St. Martin: 是的，一些小的 bug 修复什么的。我记得没有什么重大的安全问题。

Brian Ketelsen: 我记得最大的一个问题是数据库连接泄漏，好像跟事务有关。但总体来说，这是较小的点版本之一，这是好事。我们喜欢小的 bug 修复。

Damian Gryski: 1.10 很快就会出来了。我想 RC 1 已经发布了，或者你听到这个节目时很可能已经发布了……我想他们计划在二月中旬发布 1.10，所以，这不远了。

Brian Ketelsen: 是的，他们一直在发布。六个月的发布周期真的过得很快。我喜欢这种节奏。

Damian Gryski: 大概需要六个月的时间。

Erik St. Martin: 说到性能，这是我一直喜欢 Go 的原因之一，尤其是从 1.0 之前开始。性能的变化非常大，而且你什么都不需要做。

Brian Ketelsen: 你只需要下载一个新的编译器，然后微笑。

Erik St. Martin: 然后重新编译，你会发现，“哦，它更快了！”

Damian Gryski: 耶！

Brian Ketelsen: 这真是太棒了，这也正好强调了Damian之前说的---如果你来自一个本身不那么快的语言……当我从Ruby转到Go时，Go的性能提升是巨大的。那是一个很大的速度差距。然后我升级到Go 1.1，再到1.4，再到1.6，Go变得越来越快；这简直是个不断送礼的过程。

好吧，我找到了一个叫Skydive的项目。它在github.com/skydive-project/skydive^[16]上。它自称是一个开源的实时网络拓扑和协议分析器。老实说，我对这个不太关心，但它的GitHub页面上那个交互式的小图看起来真的很酷，你可以深入查看网络上的所有不同节点，以及它们之间传输的协议。这种感觉有点像《犯罪现场调查》（CSI），你应该下载它来给朋友们留下深刻印象。

Erik St. Martin: 哇，这真是太棒了。我真的很想从安全的角度使用这个……有时候试图找出哪些机器在与其他机器通信，以找到新的攻击面---这简直太酷了。

Brian Ketelsen: 我很惊讶你之前没见过这个项目；这简直是为你量身定做的。

Erik St. Martin: 是的，我之前确实没见过。这真的很酷。我也有一个项目---我想我们在节目中提到过，它叫Metaparticle^[17]，这是一个探索在Kubernetes和Docker之上构建抽象层的项目，并将它们暴露给你选择的编程语言和框架。现在它支持Go语言^[18]，所以你现在可以编写一个Go程序，它会自己编译---或者说它编译完后，当你运行它时，它会自动容器化并部署，甚至可以自动为你做分片。你可以说“我想跨两个分片部署。这里是我的分片键”，它会做出正确的操作，创建所有需要的Kubernetes组件。超级酷。

Brian Ketelsen: 是的，Metaparticle真是一个了不起的想法，此外，当你运行这个应用时，它会根据你编程声明的方式自动部署到集群上，这简直太酷了。

Erik St. Martin: 一如既往地，Francesc的Just For Func^[19]系列---最近他有一集做得非常棒，讲解了通道和nil通道^[20]，以及为什么它们存在。

Brian Ketelsen: Francesc的所有视频^[21]都如此惊艳。

Erik St. Martin: 我感觉我错过了几集，我得找个时间好好补看。

Carlisia Thompson: 可能这也和他自身的天赋有关，但我不太确定。

Brian Ketelsen: 可能吧……这是一个很好的观点。

Erik St. Martin: 稍微有可能，但……对，Francesc确实很棒。[笑] 还有其他内容吗？要进入#FreeSoftwareFriday环节了吗？

Brian Ketelsen: 是的！

Erik St. Martin: Damian，你听过节目，所以你大概知道什么是#FreeSoftwareFriday，对吧？

Damian Gryski:  当然，我知道。我想给@andybons^[22]在Twitter上点个赞。他是Go团队的Andrew，正在慢慢处理所有Go-fuzz的bug，以将Go-fuzz集成到Go的主工具链中。我认为这将非常棒。虽然这算是他的工作，但我仍然认为这是个很酷的事情，因为这将大大提升Go的测试能力，你基本上不需要做别的。

Erik St. Martin: 是的，那将非常棒。你知道他们大概在哪个版本目标上吗？

Damian Gryski: 我不太清楚。

Erik St. Martin: Carlisia，你呢？

Carlisia Thompson: 我今天没有什么要分享的。

Brian Ketelsen: 那是不是意味着我可以分享两个？

Carlisia Thompson: 是的，完全可以。

Erik St. Martin: 你可以分享三个，因为我整个星期都在做PPT，没用什么工具，所以现在脑子里也没啥好推荐的。

Brian Ketelsen: 太棒了！我要推荐一个我经常用但总是忘记它的工具，那就是Pretty包^[23]，作者是Keith Rarick。每当我想调试时---你知道的，我们家不调试，我们只用fmt.Println，但KR Pretty是一个包，它可以将几乎任何你能想到的对象以漂亮的格式输出到屏幕上。所以，代替fmt.Println，用kr/pretty.Println，你会得到一个漂亮的、可读性很高的JSON格式输出。

我唯一的抱怨是，如果你有一个非常大的类型，它会解析整个结构，输出可能会有数百行……但这就是你想要的，因为你在调试。它真的很棒，我几乎一直都在用。

这是我的第一个推荐。而对于Erik，我想感谢Richard Musiol，也就是GitHub上的neelance^[24]。他现在非常努力地在为Go开发WebAssembly编译器^[25]，昨晚我偶然发现了他的Go分支，它已经支持WASM。我简直惊呆了，看到它离完成如此之近，我无法表达我对Go的WebAssembly支持有多么兴奋。这将是一个了不起的功能。

Erik St. Martin: 是的，我在某一期Golang Weekly的新闻简报中看到了这个项目，我本来打算阅读一下，因为我觉得所有的WebAssembly相关内容都非常棒。好吧，我想这就是今天的内容……我们这周的时间控制得刚刚好。

Brian Ketelsen: 我们时间把握得这么准吗？

Erik St. Martin: 是的！

Brian Ketelsen: 太棒了。

Erik St. Martin: 在此，我要感谢所有参与节目的人。特别感谢Damian的到来。我们所有人都会关注你的性能书籍，并在幕后为你加油，我相信很多人也愿意帮你审阅。

Brian Ketelsen: 是的，快点完成吧，这样我就可以“借鉴”你的内容了。那就太棒了，谢谢。[笑] 我是说借鉴……我刚才说的是“偷”吗？

Damian Gryski: 我想许可证允许你“借鉴”。

Brian Ketelsen: 哦，太好了。谢天谢地。

Damian Gryski: CC BY-SA许可。至少这是[听不清00:46:27.27]的意思。

Brian Ketelsen: [笑] “Damian写的内容。”

Erik St. Martin: 感谢所有听众。你们可以在GoTime.fm找到我们。我们在Twitter上的账号是@GoTimeFM。如果你有嘉宾或话题的建议，或者想上节目，可以在github.com/gotimefm/ping上提交一个issue。就这样，再见各位。我们下周见。

Carlisia Thompson: 再见！

Brian Ketelsen: 再见！