本篇内容是根据2020年1月份Grokking Go.dev音频录制内容的整理与翻译,
Carmen、Mat 和 Jon 与 Steve Francia 和 Julie Qiu 一起讨论了新的 Go.dev 网站。它背后的动机是什么？它使用了什么技术来构建它？他们如何努力使包发现变得更好？有哪些资源可以帮助你说服你的经理在新的项目中使用 Go？
过程中为符合中文惯用表达有适当删改, 版权归原作者所有.
Mat Ryer: 大家好，欢迎来到 GoTime！我是 Mat Ryer。今天我们要聊聊 Go.dev，这是一个用户友好的 Go 资源中心，专门为 Go 社区精心打造。今天我们非常幸运，能请到背后团队的三位成员和我们一起讨论：Carmen Andoh、Steve Francia（也就是大家熟知的 @spf13）以及 Julie Qiu。大家好！
Steve Francia: 嗨！
Julie Qiu: 嗨！
Mat Ryer: 我们今天还请到了常驻嘉宾 Jon Calhoun。你好，Jon，最近怎么样？
Jon Calhoun: 你好，Mat。我最近不错。
Mat Ryer: 最近有什么新鲜事吗？
Jon Calhoun: 没什么特别的。
Mat Ryer: 好吧，那我们开始吧。我想听听关于 Go.dev 的一切，谁愿意先来介绍一下？Go.dev 是什么？它的目的是什么？
Steve Francia: 我可以分享一下。Go.dev 是我们 Go 社区的全新官方网站，旨在成为整个社区的集结地。现在它包含了学习资源、包或模块的发现工具，还包含了一些帮助大家在公司内部或对新公司推广 Go 的资源。
Mat Ryer: 它不会取代 Golang.org，对吧？
Steve Francia: 不会。
Mat Ryer: 所以这两个网站会共存。
Steve Francia: 是的，它们会共存。 (译者注: 实际上现在访问 golang.org会cname到go.dev)
Mat Ryer: 那区别是什么呢？Golang.org 更像是这项开源项目的技术基地，对吗？
Steve Francia: 是的，我们在创建两个网站时确实遇到了一些困难。两个网站可能会带来更多的混淆。我们最初试图扩展 Golang.org 来涵盖所有这些内容，但发现这并不容易。因为 Golang.org 的主要目的---如果你不知道的话，它的很多内容其实是跟随 Go 版本发布的---是作为 Go 项目（语言、编译器、工具）的官方平台。我们想要的是一个能够涵盖整个 Go 生态系统的综合平台。
经过几个月的努力尝试，我们意识到或许两个独立的网站会更合适。所以 Golang.org 将保持现状，而新的网站将是为 Go 社区精心策划的内容。
Mat Ryer: 明白了。那这个项目是怎么启动的呢？是内部发现了某些缺失，还是社区的需求？
Steve Francia: 这是个有趣的问题，我也喜欢你提问的方式。
Mat Ryer: Steve，我会来判断你的答案是否有趣，可以吗？ [笑声]
Steve Francia: 实际上我们这个项目是四年多前启动的。
Mat Ryer: 真的吗？
Steve Francia: 是的。作为一名社区成员，我当时和 Google 的 Go 领导团队讨论加入他们的可能性。这是一个全新的角色，之前从未有人做过。所以作为这个过程的一部分，我写了一份从社区成员角度出发的文档，列出了我们需要解决的缺失点。如果我要加入 Google，我希望能够为这些问题提供解决方案。
在那份文档中，我写道---我给你念一下---"提供 Go 采用和最佳实践的教育资源，与合作伙伴合作，创建并提供最好的培训材料。撰写 Go 的价值故事，并广泛传播该故事。解决库和包可发现性的问题。"
当时的想法并不是一个单一的项目，但这些都是从那时开始萌芽的目标。快进到现在---顺便说一下，那份文档还提到了其他事情，比如 Go 用户调查问卷（我们刚刚完成了第四次问卷），改善 IDE 体验，依赖管理等。如果你看看 Go 团队过去几年的工作，很多都是从那份文档中衍生出来的。
后来我加入了 Google，我和 Russ 以及 Samir 一起合作，向 Google 领导层提出了扩展团队的概念。最终，我们得到了扩充团队的机会，这也促成了招募 Carmen 和 Julie，她们为推进这个项目做了很大贡献。 (译者注: 目前Steve Francia和Julie 应该都不在go团队了)
Mat Ryer: 太棒了！非常感谢你们所做的出色工作。你提到的包发现功能很有意思，因为在 Go 的早期，包并不多，随着时间推移，包的数量逐渐增加。所以现在当人们想要引入一些依赖时，选择也变得更多了。这有点像"狂野西部"一样混乱。所以你们是否认为这是一个让这个领域更加规范的机会，帮助找到更值得信赖的开源包？
Steve Francia: 这不仅仅是 Go 的问题。我们认为这是现代软件开发中的一个普遍问题。正如你所说，当达到一定的临界点时，问题就会变得更加严峻。不过每个语言都在面临这个问题，只是程度不同。我认为 Go 相对来说问题较小，但我们确实希望能够为 Go 解决这个问题。
Mat Ryer: 你们会考虑包是否仍在维护，或是否使用了被广泛认定为不好的模式等因素吗？你们会有这样的主观性判断吗？
Julie Qiu: 是的，我们确实讨论过这个问题，并考虑在未来添加这些功能。现在，如果你想到 Go 生态系统中已经存在的东西，比如 GoDoc.org(译者注: 目前会跳转到https://pkg.go.dev/)，它提供了包的文档，但缺少一些关于"这个包是否仍在维护？这是我真的想要集成到我的项目中的东西吗？"的信息。这些都是我们想要在未来通过 pkg.go.dev 实现的。目前我们已经打好了基础，这些都是我们在考虑的内容。
Mat Ryer: Julie，我看过你的演讲，你谈到了如何选择好的依赖包，以及应该关注哪些方面。任何对此感兴趣的人都应该去找找看那个演讲。你谈论了像"这个包里是否有测试"的问题。那么，在选择依赖时，还有哪些重要因素？为什么这些因素如此重要？( 译者注: [GothamGo 2019 -- "Finding Dependable Go Packages" by Julie Qiu](https://www.youtube.com/watch?v=zCragLHzP1Y "GothamGo 2019 -- "Finding Dependable Go Packages" by Julie Qiu") )
Julie Qiu: 如果我要将其分类，我会说有三大主要考虑因素：受欢迎度、质量和稳定性。受欢迎度指的是"其他人是否在使用这个包？"这一点很重要，因为它给你提供了一些判断依据，比如"如果作者突然决定不再维护这个包，有没有其他人会接手？有人会找出漏洞吗？如果我的项目严重依赖这个包，我能否指望它继续存在？"
质量方面则是"这个包文档是否完善？代码是否有测试？代码看起来是否符合 Go 的惯用编码风格？"这些都能让你判断包的作者是否熟悉 Go 包的开发。当你在选择第三方包时，实质上是在评估"这段代码我是否愿意放进我的代码库中？"这很重要，尤其是在周五下午你快要发布代码时，你希望代码不会突然变成你从未见过的样子。
最后是稳定性。技术在不断变化，Go 生态系统也在变化。当这些变化发生时，你是否能够指望这个作者考虑到你的项目需求？你不希望看到的是某个版本中的导出函数在下一个版本中消失了，尤其是在没有进行重大发布的情况下。这会给你升级代码库带来很多麻烦。所以这是我选择依赖时的思路。
Jon Calhoun: 我们的一位听众问了这样一个问题："你们在收集包数据时，是否会公开这些数据？"他们具体问的是"当你在选择包时，一个判断标准是大型项目是否在使用这个包。如果像 Docker 这样的项目在使用某个包，那么这个包很可能不会被弃用；而如果只是一些小项目使用，受欢迎程度可能就没那么重要。"你们会公开这些数据吗？
Julie Qiu: 听起来他们想要的是包的导入和被导入关系的相关信息。这些信息实际上已经可以在 pkg.go.dev 上找到。
你可以点击任何感兴趣的包的"Imports"标签，查看它导入了哪些其他包；或者点击"Imported By"标签，查看有哪些项目在使用这个包。
Mat Ryer: 这很棒。这和 GoDoc 不同，对吧？pkg.go.dev 是新的。
Julie Qiu: 嗯。
Steve Francia: GoDoc 只是文档，而 pkg.go.dev 的目标是提供更丰富的信息，涵盖每个包的更多内容。
Mat Ryer: 对，确实。
Julie Qiu: 是的，GoDoc.org 上确实有一些关于导入和导入者的信息，但我们的目标是将这些信息整理成用户更关心的内容。
在"Imported By"标签上，你可能会注意到我们倾向于对导入者进行分组并计数，而不仅仅是像---比如 Kubernetes 可能有一个包，它导入了某个东西 1000 次。我们希望认真对待这种情况，以更好地衡量包的受欢迎度。
Mat Ryer: 哦，我明白了。你能解释得更详细些吗？
Julie Qiu: 是的。如果你想知道为什么要关心受欢迎度，实际上它回答的是"有多少人决定使用这个包并将其集成到他们的代码库中"。有时，你可能会看到一个仓库---比如 julieqiu.org/foo---里面有一百万个包，它们都导入了同一个包。那么这个第三方包现在有一百万个导入者，还是应该只有一个导入者？这是我们还没有确切答案的问题，但我们希望能够认真考虑这些问题。
你可以这样想：也许我们会把它算作一百万个导入者，但用户可能更希望看到的是所有这些导入者都归为一类，这样你就可以回答"是一个大组织在使用，还是一个非常重要的模块在使用"这类问题，而不是看到一个巨大的列表，实际上都在告诉你同样的事情。
Mat Ryer: 对，这很有道理。你在演讲中还提到需要查看包的依赖数量---一个包有多少依赖项。如果你有两个选项，可能选择依赖更少的那个会更明智......但为什么这很重要呢？这不是我们的问题，不是吗？
Julie Qiu: 事实上，很多时候看起来它确实不是我们的责任，直到它变成了我们的责任。在我的演讲中，我给出了一个完全假设的例子，包名叫 pad-left [笑声]，它可能被数百万个不同的包间接依赖。你个人可能从未使用过 pad-left，但如果它突然从 Go 生态系统中删除，所有相关代码消失，你再也找不到它了，它可能会导致很多问题，让你不得不去追溯依赖树。所以即使在日常工作中看起来这不重要，它也可能带来很多麻烦。
当然，代码被删除是最糟糕的情况，但还有其他问题，比如安全漏洞，或许可问题等。这些都是你在考虑自己的包时会认真思考的事情，但你也应该同样仔细考虑你的依赖项及其间接依赖项。
Steve Francia: 我觉得这里有一个有趣的点......我们通常会简化问题。你刚才问的问题，Mat，是"更多依赖项更好，还是更少依赖项更好？"这个问题没有固定答案。取决于具体情况。如果你的依赖项更多，但它们是稳定且经过良好测试的高质量依赖项，我会毫不犹豫地选择它们。而不是选择依赖项更少，但质量较低的包。
所以真正的问题不在于依赖树的大小，而在于依赖树的质量。每当你导入一个依赖项时，它实际上就成为了你项目的一部分，但我们往往没有足够重视这一点。当你导入一个包时，你其实是在把它的代码引入你的项目，现在你要为它负责。所以在导入之前，你要确保自己对它有信心。
因此，数量并不是衡量的标准。质量才是关键，然后再考虑数量。
Jon Calhoun: 这是个好观点，因为标准库实际上就是一组第三方库，只不过我们知道它们的维护标准非常高。而 GitHub 上的任何东西---我们并不知道它们的质量标准......这就像是在赌博一样。但如果你知道某个组织有相同的高标准，那么你就可以更加放心地导入更多的这些包，担心会破坏东西的几率也会小很多。
Mat Ryer: 是的。对于包开发者来说，这也有帮助。如果我们思考一下人们会根据什么标准来选择包，开发者可以根据这些标准来优化他们的包。如果有人想要开发自己的包，现在有了一个明确的标准---Julie，你的演讲对想开发包的人也很有帮助。社区现在开始有一些期望了......不过我在想，如果我们开始特别关注那些经过测试的流行包，是否会让新包更难出现？有没有可能我们最终反而让新包的出现变得更加困难，还是说这种选择过程对所有人都有好处？
Steve Francia: 我来回答这个问题。我先说，如果一个包很好地解决了问题，那么就不太需要再有其他包来代替它了。标准库就是一个很好的模型。当我刚开始学习 Go 时，我把它看作卓越的标杆，并努力在我编写的包中达到那个标准......之所以没有很多竞争的字符串包，是因为标准库中的 strings 包做得非常好。而当有其他包出现时，往往是因为它们填补了标准库中未解决的空白。
因此，如果一个包是稳定且经过充分测试的，而且能很好地完成任务，那么我们就不需要替代品。只有当设计理念发生根本性变化，或者现有包不能满足某些需求时，我们才需要替代品，这其实是很自然的事情。我们也遇到过类似的公司讨论：一个公司越大、越成熟，是否会阻碍新公司的崛起？
这背后有很大的政治和哲学争论，但现实是，随着时间的推移，我们看到初创公司依然在不断出现，它们的存在是为了填补市场的空缺。公司越大，或者说包或库越成熟，它们就越难适应变化，无法快速应对新的需求......而需求总是会随着时间而变化。这给了新包崛起的机会。我认为这是一个健康的生态系统应有的样子。
Jon Calhoun: 我觉得 JSON 包是一个很好的例子，标准库中的 JSON 包做得不错，但后来出现了一些新的包，它们解决了稍微不同的问题。如果你不想为一个嵌套了六层的结构体构建一个新的结构体，有一些包可以让你轻松地深入到第六层，从 JSON 数据中获取一个具体的信息，仅此而已。还有一些包的目标是提高速度......不同的包根据你想要达到的目标各有侧重。即使你觉得"标准库已经有了，没人会和它竞争了"，但实际上，人们还是会去竞争，因为他们有特定的需求。 (译者注: 主要是标准库在json处理这块选择了更高的兼容性而不是性能,但很多场景下json解析对性能有较高要求)
如果你看看 JavaScript 的前端框架，你可能会觉得其中一个最终会成为唯一的赢家，大家都会停止使用其他的框架......但事实并非如此，它们都在解决不同的需求。如果有一个框架足够独特，能够解决一个足够不同的问题，我们就会看到它会获得一些关注，并逐渐获得用户。
Mat Ryer: 当 context 包出现时，那就是你刚才提到的那种变化，Steve。突然之间，人们开始期望能够取消以前无法取消的操作......比如文件复制。在标准库中有支持 context 的复制操作吗？如果你使用 io.Copy()，它会一直复制到文件的结尾，对吧？有可以取消的版本，还是必须自己实现？
Steve Francia: 我不记得标准库里有这样的功能。
Mat Ryer: 所以像这样的用例......实际上仍有很多机会可以让任何人贡献代码。这就是重点......我不希望人们因为标准越来越高而感到退缩；这并不意味着你不能做出贡献。尤其是，Steve 你说的"找到尚未被解决的问题，然后在那里创新"，我觉得这非常好。我同意，提高标准对大多数人来说都是好事，因为我们确实关心依赖的质量，关心它们是否可靠，是否能够长期存在。
Jon Calhoun: 你们提到的一个目标是帮助公司了解其他人如何使用 Go，并从中学习，决定是否采用它。我猜这对我们很多人来说可能并不常见；至少对我来说是这样，因为虽然我希望人们使用 Go，但我通常不会去和大公司说"你应该使用它"。所以这是 Go 团队在积极推动的吗？这是一个大目标吗，让人们更容易理解 Go 的使用情况？你能详细说明人们在寻找什么，你们如何帮助他们吗？如果有人想说服他们的公司使用 Go，你会有什么建议？
Steve Francia: 我们花了很多时间与不同的公司会面，试图了解他们的需求以及他们面临的挑战。我还想说，作为 Go 团队的一个大目标，我们希望 Go 被尽可能广泛地使用。我们都熟悉那个 adoption 曲线：一开始很慢，然后有一个鸿沟，这是早期采用者，之后的那个大鸿沟是主流阶段......每一个阶段都有不同的需求。作为一种语言的成长，企业领域是 Go 进一步扩展 adoption 的一个关键点。(译者注: 即技术采用生命周期,Technology adoption life cycle)
我们在早期获得了大量初创公司和个人开发者的采用，所以我们意识到企业 adoption 对于 Go 实现其潜力非常重要。为此，我们做了大量研究，并与来自各行各业的公司进行了交流---从零售商、银行到多媒体公司......遍布各个行业、不同大洲。
通过这些对话，我们听到了几乎每家公司都会问的两个问题。这些公司要么正在考虑使用 Go，要么已经用 Go 做了原型，或者已经在某些项目中采用了它......每家公司都会问的两个问题是："还有谁在使用 Go？"以及"他们在用它做什么？"通过与他们的对话，我们听到了许多不同的故事，这些故事让我们感到非常兴奋。他们谈到了用 Go 编写的原型，并且因为尝试向他们的管理层介绍这项技术，遇到了挑战。他们认为 Go 是一个很好的解决方案，但他们的领导层，尤其是技术决策者们想知道"还有谁在用这个？他们用 Go 做了什么？"但他们没有好的答案来回应这些问题。
所以很多故事到此为止了。但有些故事继续发展了下去，有人对 Go 的决策非常有信心，甚至"单干"了，偷偷用 Go 编写了一个原型，结果取得了巨大的成功。
这些公司中的先锋们提供了他们当时希望得到的东西，那就是这些故事。因此，我们非常高兴能够讲述这些故事。我们已经与这些公司合作了好几个月，记录并公开分享他们与我们分享的故事。希望下一轮的使用者在去向他们的领导层提出问题时，能够回答这些问题："还有谁在用它？他们用它做了什么？他们是否和我们公司同属一个行业？"他们现在会有答案。
不仅是在这些内部会议中，我们还做了不同的调查，结果显示这是人们在调查中最常提出的需求之一。如果你来自一家小公司，或者你可能是个体顾问，这听起来可能有些陌生。但如果你在一家大公司工作......我们的网站上已经发布了几家大公司的案例研究：美国运通、PayPal、MercadoLibre(译者注: 美卡多,一家阿根廷线上商城)......你可以在网站上看到它们。这些都是需要经过更多层级审批的大公司，这是他们一直在寻求的东西。
Mat Ryer: 是的，这很有趣。如果你去 Go.dev 网站，那里有很多公司的标志，但它们并不只是装饰品。有时候你在网站上看到这些标志，会觉得它们只是为了炫耀......但实际上，你可以点击这些标志，查看这些公司如何使用 Go 以及他们在做什么。
Carmen Andoh: 是的，确实可以。
Mat Ryer: 确实可以，没错。
Steve Francia: 没错，你一定可以。
Carmen Andoh: 是的。
Steve Francia: 我认为这些故事非常具有共鸣性，也非常鼓舞人心。当你点进去阅读这些文章和故事时......我记得很早的时候，当我在 MongoDB 工作时，最早接触 Go。当时还没有太多这样的故事，但在使用 Go 的过程中，我爱上了它。它点燃了我对编程语言潜力的探索热情......这最终引导我去 Docker 工作，而 Docker 是 Go 的大用户，之后我又加入了 Google 的 Go 团队。
这些故事展现了类似的经历。如果你已经使用了 Go 一段时间，看看这些故事，它们会让你想起当初你爱上这门语言的那一刻。
Carmen Andoh: 我还想指出这些案例研究的另一个有用之处：当我学习编程时，我并没有学到如何影响我的经理，或者如何说服我的高层选择 Go。这不是学校教的内容......而这些案例研究正是我可以指给别人看的东西，可以说"我想选择这项技术，这就是原因所在。"
多年接触人们后，我发现很多人都会问："我该如何说服我的经理？"或者"我该如何说服我的 CTO？"或者公司里的某个人来采用 Go。当然，Steve 提到的"单干"战术是一种方式，但你现在不再需要担心走"单干"的路线，或者冒着被从公司核心项目中剔除的风险来推动采用 Go。你可以简单地说："看看这些证言"，然后逐步尝试，比如先在一个服务中使用，或者对代码库中的某个小部分进行重构。
这些案例研究中有些比其他内容更详细，它们可以为你提供一个蓝图，帮助你决定如何去做，无论是全面采用 Go，还是只是在某些观察工具中使用 Go，或是进行一些自动化开发。
所以我非常喜欢这些案例研究，我现在告诉人们，学会如何影响别人是学校没有教的重要技能，而这些内容非常有帮助。
Mat Ryer: 是的，我在最近的伦敦 Go 技术交流会上遇到一个人，他们对学习新语言持保留态度，尤其是对那些可能只会一门语言的人来说，这是一个很大的挑战。但学习 Go，特别是如果你已经熟悉类似 C 语言的基础，实际上比学习其他一些语言更容易，因为 Go 的简洁性......所以我总是鼓励大家学习。
我还喜欢这个解决实际问题的想法，即使你不完全确定最终结果会如何。当你尝试学习某些东西时，围绕着你要解决的实际问题来学习非常有帮助，它能集中你的注意力。你不会花时间研究诸如通道（channel）是如何工作的，或者如何通过结构体打包来优化内存使用。你会专注于你实际案例中重要的部分......那个人就是这么告诉我的---他们的经历让他们感到惊讶的是，学起来比想象中容易，而且在解决一个小问题时就能应用起来。我记得那是个很小的问题，但他们很享受那个过程，然后他们还向公司里的其他人展示了这个小项目---实际上是向任何愿意听的人展示。这也是一个不错的推广方式。
Carmen Andoh: 再补充一点背景，关于 adoption（采纳）的讨论，不同的人心态不同，取决于他们在公司中的位置以及公司的状态。我经常听到的一个说法是"我不想只学习理论"，或者"我想看看它在实际应用中的样子，从头到尾。"这些案例研究的另一个好处就是，它们提供了一定程度的细节，可以手把手带你走完整个过程。
有些人喜欢自己探索，找到适合自己的方法，但有些人需要看到它在实践中的样子，看看它是如何随着时间发展成熟的。我认为这些案例研究是我最喜欢的部分之一。虽然我喜欢整个网站，但我尤其推崇这些案例研究，有很多原因。
Steve Francia: 展望未来，我们在网站上线时推出了一些案例研究和在外部网站上发布的文章，我们迫不及待地想分享更多的故事；分享更多、更深入的故事。我们希望今天的一些听众来自那些想要分享他们故事的公司。我们有两点建议。
首先，你不需要我们来讲述你的故事。很多公司，比如 Capital One，在他们自己的博客上发布了多篇关于他们如何采用 Go 的文章。我们把这些文章链接到我们的网站上。所以随时可以分享你们自己的故事；我们很愿意链接并扩大它的影响力。另外，我们也很乐意与你们见面，了解你们的经验和故事。最好的方式是访问 Go.dev，页面底部有一个"分享反馈"（Share Feedback）的链接。如果你有兴趣与我们合作撰写案例研究或文章，请填写那个链接。
最重要的是，那是一个匿名按钮，所以如果你希望我们联系你，必须在里面填写一些识别信息，这样我们才能跟你取得联系，否则我们就无法追踪到你了......我们已经遇到过几家公司这样做了，他们提交了"我们对案例研究非常感兴趣"，然后就没有留下联系方式。
Mat Ryer: 好吧...... [笑声] 所以请留下你的名字和邮箱，或者其他联系方式。
Steve Francia: 以某种方式留下你的信息。
Julie Qiu: 如果你想发送非机密的邮件，也可以随时发送到 go-discovery-feedback@google.com。如果你记不住所有这些信息，我们在 Go.dev 网站上有一个关于页面，Go.dev/about 上有所有这些信息。
Mat Ryer: 谢谢。我们也会在节目备注中放一些相关信息。
你们会上传视频和演讲内容吗？比如会议上的演讲之类的？
Steve Francia: 我们在博客文章中提到过这一点---我们希望尽早把我们认为的最小可行产品（MVP）交给社区。你会注意到我们在网站上写道"这是为 Go 生态系统、由 Go 生态系统打造的"，但目前还没有很多社区资源。我们计划增加这些内容，并让它成为一个真正的社区聚集地，帮助大家了解会议、技术交流会和演讲，真正成为一个资源平台。
Mat Ryer: 网站首页上有一个"活动"板块，对吧？
Steve Francia: 是的，但它只展示了三个活动......而且我认为它们只是技术交流会，还没有包括会议。因此这是一个开始，我们很高兴它上线了，但全球有如此多的 Go 技术交流会......今天你如果去看，它显示的是 1 月 11 日有三个技术交流会，但实际上那天有超过三个技术交流会。因此，它提供了一个初步的展示，但我们希望进一步扩展，让无论你是在墨尔本、班加罗尔，还是美国俄勒冈州的尤金（今天网站上的三个地点），或者世界上其他任何地方，它都能告诉你即将到来的活动是什么，提交论文或参与的截止日期是什么等。
Mat Ryer: 是的，这太棒了。有了这个功能确实非常好，因为即使是我们这些已经在社区里待了一段时间的人，有时候也很难知道发生了什么。我觉得这不仅仅是一个面向新人的好资源，它对所有人都有帮助。
Steve Francia: 这也部分解决了一个突然出现的问题......如果我们回顾两年前，我不记得确切的数字，但当时可能有十几场 Go 会议。今年，2020 年，计划举办的会议数量超过 30 场。这意味着每个月有三场会议。这有点让人应接不暇。这意味着今年大部分周都会有会议。所以，随着社区的兴奋度不断提高，拥有一个能够组织和整合这些信息的平台确实非常有帮助。
我们不会在接下来的一个月或两个月内上线这个功能，但它确实在我们的路线图上，我们有意去做这件事。
Jon Calhoun: 我经常在 Twitter 或我们的 GoTimeFM Slack 群组里看到人们问这个问题---这个网站最终是为社区服务的资源，所以大家都在问"你们计划开源这个项目，或者让社区在项目中扮演更重要的角色吗？"我知道在项目初期不这样做可能会更容易，但我想知道你们能分享一些未来的计划吗？
Steve Francia: 我们正在研究这个问题。我们当然希望确保无论我们做什么，都是对社区和用户最好的选择，并且能够以最佳方式满足他们的需求。我们正在努力确保我们以最好的方式做到这一点。所以现在正在进行讨论；其实这也是我们 Go 开发者调查的一部分，我们在调查中问了很多关于这个问题的具体问题......我们正在持续进行研究，以更好地理解用户的需求，并确保我们尽可能满足他们的需求。
Julie Qiu: 是的，我们很快计划做的另一件事是开放 Go 的问题跟踪器，接受反馈。我们已经提到我们有两个不同的渠道来接收反馈---电子邮件和网站底部的反馈按钮，但显然这些都是私下的讨论，而我们也听到人们说他们希望有一个更公开的论坛来讨论这些问题......所以我们正在为此制定一个流程，并且很快会公布。这是我们想要明确传达的信息：我们希望人们对我们进行反馈，因为我们希望这个平台是为 Go 生态系统打造的。
Mat Ryer: 这太好了。在你们的 pkg.go.dev 网站上，你们是如何决定哪些是流行包的？你们是如何决定要展示哪些包的？
Steve Francia: 你是说具体到那个页面上......
Mat Ryer: 是的。因为这最终会成为......我猜这些包会是人们正在使用的包，对吗？如果还没有的话，以后也会是。
Steve Francia: 我们希望如此。从某种程度上说，它们已经是人们经常使用的包了。这就是为什么它们在那里。
Mat Ryer: 所以这就是为什么它们被称为"流行包"，对吧？
Steve Francia: 是的，这就是我们给它命名的原因。这就是我们想出的名字。
Mat Ryer: 这很有道理。
Steve Francia: 不管你信不信，我们还为这个名字开了几次会......不，开玩笑的，我们就这么决定了。
Mat Ryer: [笑声]
Steve Francia: "精选包"是经过一些人工筛选的包。它们大多也是受欢迎的包，但我们认为它们填补了某些特定需求，或者解决了人们急需的功能。而"流行包"则是根据数据库中的导入次数来选出的热门包。
Jon Calhoun: 当你们在筛选这些包时，我知道网上有很多类似 Awesome Go 或 Awesome 项目，列出了一堆包，并按用途进行分类。有些包是图形用户界面相关的，有些包是数据库相关的......一般来说，它们会做一些筛选，但有时候感觉它们什么都往里面放了。
我想问的问题是：你们如何在筛选时把握这个度？你们不想拒绝别人，也不想当个门卫，但同时你们也需要避免把所有东西都列在一起，因为那样对用户来说不一定有帮助。比如，列出所有连接数据库的包可能会让人觉得信息过于繁杂。你们是如何在这当中找到平衡的呢？
Steve Francia: 如果我们回顾搜索引擎的早期，90 年代初、中期，你可能还记得当时 Yahoo! 是领先者之一，他们通过人工编辑的方式创建了网站目录，效果很好。事实上，当时其他人难以竞争的原因是，他们无法与 Yahoo! 的质量相媲美。
然后 Altavista 出现了，带来了更高的准度和质量，而且速度很快。当然，速度是相对的......最初它非常快，大家都很兴奋......(译者注: Altavista是全球较早,较知名的网上搜索引擎公司之一,名称代表"从高处望下")
Mat Ryer: 对，Steve，所有软件在用户开始使用之前都是很快的。是用户的使用造成了问题。所以我们需要关注如何让东西真正运作起来......
Steve Francia: 后来 Google 出现了，他们不仅解决了速度问题，还保证了质量和准确性。我认为我们可以从这个经历中学到很多。
Awesome Go 曾经是一个很棒的资源，现在也是，但在一开始，包的数量较少，列表相对容易维护和跟踪。随着列表的增长，人工维护变得越来越困难。Julie 之前提到过的那些信号和包上的可视化指标，我认为解决方案不是继续维护手动列表，而是要有动态的工具。
有时候你在寻找 Awesome Go 预定义的某些类别中的东西，但有时候你需要的东西不在那些预定义类别中。无论你在找什么，你都希望知道这个包的质量如何......我认为这回到了那些指标上，它们能真正帮助我们。这也是我们正在努力开发的发现功能的一部分。
Mat Ryer: 我曾经写过一篇博客文章，并附带了一个代码仓库展示代码......几年后我做了一些修改，结果有人开始提交问题，说"你弄坏了我们的构建"。这个仓库只是为了展示一些想法，从来没打算让别人导入它，所以我非常震惊。这种情况下，包的作者或维护者有没有办法在 Go.dev 或 pkg.go.dev 上标记这些东西，比如说这个包已经废弃了，或者不应该被导入，甚至可以告诉别人"如果你想解决这个问题，用另一个更好的包吧"？
Julie Qiu: 如果你想指出某个包不再可用，你可以给我们发邮件。我们也接到了有人要求从 pkg.go.dev 上移除他们包的请求。这是我们目前支持的功能。
未来我们也在考虑一些方案，比如说当有人归档或删除了他们的仓库，我们可以提供某种标记，告知用户这个包已经不可用。
目前在网站上还没有直接让作者推荐替代包的功能。我觉得这个功能需要仔细考虑用户体验，或者我们是否真的希望用户能够这样做......所以这是我们目前探讨的方向。
Mat Ryer: 对，我可以想象，比如在仓库根目录里有个 .go.dev 文件，里面可以包含一些元数据，工具可以识别这些信息。目前已经有一些类似的成功案例，工具可以识别这样的元数据。可能就是类似"看看这个包的替代品"等信息。虽然有很多人还在使用我写的包，这对我的自尊心来说挺好（笑），但如果有更好的包，我希望大家去用那些包，而不是一直用我的包。所以，如果能够提高整体体验的质量，我很愿意花点时间去做这件事。
Julie Qiu: 是的，我们在早期的头脑风暴阶段也讨论过其他可能有助于解决这个问题的元数据。比如关键词（tags）就很不错。如果你可以标记这个包是"日志包"，那可能就不用说"这是你要找的那个包"，而是通过关键词让用户在生态系统中找到它。不过这些都是我们仍在思考和讨论的内容，还不确定最终会是什么样子。
Mat Ryer: 很期待这些功能。
Julie Qiu: 是的，还有很多有趣的方向可以探索。
Jon Calhoun: Mat 你描述的情况我也很熟悉。当你在做一些教学内容时，你希望代码可以编译和运行，但同时这也意味着别人可以导入并使用它。问题是，这些代码本来是用于教学，而不是用于实际项目的。比如你可能展示了如何制作一个 HTTP 路由器，但这并不意味着大家应该去用这个路由器。外面有很多更稳定的路由器你可以去选。所以这确实有点棘手......或许可以有一种方式标记这些内容是学习资源，而不是实际运用的代码，可能会有所帮助。
Steve Francia: 你举的这个例子很好，展示了我们可能需要的不同需求，超出了当前的静态元数据，例如 readme 和许可证文件。对于这个具体问题，如果你不希望别人导入这个包，可以把许可证改为一个几乎不可能被导入的类型。这可能是解决这个问题的一个办法。
Mat Ryer: 不过工具并不会自动阻止这种情况，对吗？假设大家都会在导入包之前检查许可证......
Jon Calhoun: 另一个问题是，如果我在教别人某些东西，我希望他们能够自由地使用这些代码。如果我给出一个非常严格的许可证，他们可能会想"我不能用我学到的东西"，因为担心以后使用这些代码会引发法律问题。大多数教学内容的作者都会使用 MIT 许可证，因为他们不希望学生担心他们学到的代码不能用。
Mat Ryer: 但 Jon，你刚刚想到了一个绝妙的诈骗方案。
Carmen Andoh: 不要给别人坏主意。
Mat Ryer: [大笑]
Steve Francia: 关于许可证问题......我刚才的回答带点玩笑成分，因为你说的都对。但我们听到很多公司对这个问题非常关心。许可证合规性是一个大问题，因为它可能会让你陷入很大的麻烦。每家公司和个人都应该关心这个问题，但公司越大，法律团队越庞大，他们对这个问题的关注就越多。虽然目前所有 Go 工具都没有完全解决这个问题，但我们确实在 Go.dev 中引入了更多的许可证检测功能。
Mat Ryer: 对，它会报告所有包的许可证，对吧？它还会排除那些你们不认可的许可证吗？
Julie Qiu: 是的，它排除了某些内容，但不会排除整个仓库。我们区分的是内容的性质，比如我们不会排除包的导入信息，因为这是关于该包的事实信息，或者它的最后发布日期也是一样的。但像 readme 和文档这样的内容，我们认为是不能重新分发的。
如果你在 pkg.go.dev 上查看某个包的文档页面，而我们认为它的许可证不允许重新分发，那么这一点会非常明显。
Mat Ryer: 所以，如果你希望你的包被包括在内，选择一个允许分发的许可证就很重要。
Julie Qiu: 对，这也是我们在上线后收到很多反馈的一个原因。我们的许可证政策最初比较严格，而且我们没有提供足够的信息说明需要哪些许可证。但最近我们更新了许可证政策。如果你想了解更多，我们使用了 license check 库来进行许可证检测，并且提供了一份许可证列表和内容副本，你可以从中选择一个适合的许可证。
Mat Ryer: 很好。其实有一个 Go 工具 ---我用过---可以检查你的所有仓库的许可证。我会找出来并放在节目备注里，因为它非常有用。早点注意这个问题是值得的。通常的情况是，你开发完功能后，法律团队才会来问"确保许可证没问题"，然后如果有问题，你可能会陷入麻烦，或者需要额外的工作去找替代品，甚至自己重写部分代码。因此，正如 Steve 之前提到的，导入之前检查许可证是很重要的。
Jon Calhoun: 我很惊讶还没有人开发出类似 goreturns 的工具，可以根据每个公司的政策定制，当你保存代码时自动检查......因为每个公司对许可证的要求都不一样。如果有个工具能在你保存代码时标记"你不能导入这个包"，那就太好了。
Mat Ryer: 就像编译时错误一样。
Jon Calhoun: 是啊。如果能内置这样的功能，那就非常方便了。
Mat Ryer: 这是个好主意。
Carmen Andoh: 听起来确实是个很棒的主意......特别是在这个软件复用如此普遍的时代，相关风险也越来越高。
Jon Calhoun: 通常情况下，人们在 GitHub 上看到开源项目就认为可以随便使用，但并不是所有项目都附带许可证，而且开源并不意味着你可以随意在商业项目中使用它。
Carmen Andoh: 对。普通的软件开发人员不是律师......他们只是把代码拉下来，然后看看能不能用。是的......[笑]
Jon Calhoun: 有时候我觉得连律师都不确定。
Carmen Andoh: 这确实反映了当今的现实。
Mat Ryer: Go.dev 是用什么语言写的？你要小心回答哦......
Steve Francia: Elixir。
Carmen Andoh: [笑] Steve......！
Steve Francia: 什么？哦，我们不能说这个吗？
Carmen Andoh: 删掉......删掉......！不，别闹了。
Julie Qiu: 是用 Ruby on Rails 写的。
Carmen Andoh: [笑] 我还以为是 Haskell 呢......是 Haskell，对吧？！[笑]
Mat Ryer: 那真实的答案是什么？
Julie Qiu: 是 Go。
Mat Ryer: 是 Go！我们应该放点庆祝音乐。
Carmen Andoh: 当然是 Go！
Jon Calhoun: 能谈谈你们用的技术吗？是 API，还是后端模板？能介绍一下你们是怎么构建这个项目的吗？
Julie Qiu: 整个后端都是用 Go 写的，前端则是 Go 模板。大部分是 HTML 和 CSS。我们很长时间都没有用 JavaScript，即使现在用的也很少。
这个网站托管在 Google Cloud Platform 上。整体架构是我们有一个数据提取系统，它从模块镜像中提取数据，进行转换后存入 Google Cloud SQL 上的 Postgres 数据库。前端服务从这个数据库中拉取数据并提供请求响应。我们还使用 Redis 进行缓存管理。这就是大致的架构。
Mat Ryer: 是用 Google App Engine 吗？
Julie Qiu: 是的。
Mat Ryer: 我一直在用 App Engine，我很喜欢它。
Julie Qiu: 它在部署和扩展上非常方便......我们团队很小，所以这种方式挺不错的。
Mat Ryer: 是的，它的扩展能力非常强大，特别是当你不太关注运维时，你可以不用担心这些问题。我非常喜欢这点......听起来很棒。
Mat Ryer: 我们节目有一个新的常规环节，而且我们还为它制作了专属的音乐......这个环节叫"非主流观点"。
音乐插曲:
Mat Ryer: 所以我们要问，大家有没有什么非主流的观点想分享？有人愿意开始吗？
Julie Qiu: 我可以先来......
Mat Ryer: 请讲。
Julie Qiu: 这个观点经常被 Go 团队的同事们拿来开玩笑，但......我的非主流观点是，纽约市的公交车是穿越曼哈顿最好的通勤方式。
Mat Ryer: 哇，这确实很有争议。
Carmen Andoh: 比出租车、比地铁都要好。坐公交车吧。
Julie Qiu: 真的很好！
Mat Ryer: 真的吗？
Julie Qiu: 是啊，基本上就像一辆 Uber Black 豪华车一样。它很大，来接你，有 Wi-Fi，还有美丽的风景......
Carmen Andoh: [笑] 我们在等待纽约市公共交通的革命......
Julie Qiu: 现在 M14 线上的新座位非常舒服...... (译者注: 一条纽约巴士线路)
Mat Ryer: 你是在开玩笑吧！
Carmen Andoh: 真不错。
Julie Qiu: 真的很好！
Mat Ryer: 这是一个很棒的观点。Steve，你有什么不受欢迎的观点吗？
Steve Francia: 我的不受欢迎的观点是，我觉得 Windows 是最好的操作系统......在准备这次播客时，已经证明这一点确实不受欢迎了。（笑声）
Jon Calhoun: 对于不熟悉我们录制流程的朋友来说，录制节目时，每个嘉宾都会自己录音，以确保音质更好。而我想 Steve 是我们第一个用 Windows 的嘉宾，或者至少是第一个让我帮他设置录音的嘉宾。我以前没搞过这个，所以得自己摸索。
Mat Ryer: Steve 是我遇到的第一个现代程序员还在用 Windows 的人。所以，Steve，确实，这是一个不受欢迎的观点。
Steve Francia: 我也用其他操作系统，我并不是只用 Windows。但我真的很喜欢 Windows 10，我觉得他们做得非常好。我也喜欢 Windows 的 Linux 子系统，我的 Windows 里有 Bash，我用得非常顺手......我在上面开发，这是我的主要开发环境，但我也会做一些摄影和视频编辑......
Mat Ryer: 还有 Minecraft......
Steve Francia: 我不玩 Minecraft，但偶尔玩一些游戏，Windows 在这方面也很不错。
Mat Ryer: 那个有格子的小游戏，找地雷的那个叫什么？
Steve Francia: 哦，扫雷。
Mat Ryer: 扫雷。让我再说一遍，我们可以剪进去。扫雷......（笑声）
Steve Francia: 我喜欢刚才那样。我觉得那样更好。
Mat Ryer: 不过 Minecraft 到处都有，我觉得扫雷可能是 Windows 独有的。我还挺怀念它的。这是我怀念 Windows 的地方。
Steve Francia: 说实话，我都不知道它现在还在不在 Windows 上。我们查查。
Carmen Andoh: 1997年的 Mat 来电话了，它想让你回去。
Mat Ryer: 我喜欢 XP......
Steve Francia: 不，它不再预装在 Windows 上了......我刚搜索了一下扫雷，没有找到。
Carmen Andoh: 它想像1999年一样狂欢。
Jon Calhoun: 看来是因为人们在工作时玩得不够高效，所以他们不得不把它移除。
Mat Ryer: 是啊。我曾经为了玩扫雷给我的 Mac 装了双系统。
Carmen Andoh: 哇......
Jon Calhoun: 你找不到一个在线版吗？
Mat Ryer: 不，我那时没有网络。（笑声）是啊，XP 还不错......不过我知道最近他们为开发者在 Windows 上投入了不少努力。当然，你可以在 Windows 上成功地使用 Go，对吧？
Steve Francia: 是的，Go 确实是让我全职转向 Windows 的语言......
Mat Ryer: 没人会这么说吧？Steve，你可能是世界上唯一这么做的人......
Jon Calhoun: 他不是唯一的。
Steve Francia: 我不是唯一的。
Mat Ryer: 我敢打赌。
Jon Calhoun: 我记得 Brian Ketelsen 也偶尔用 Windows......
Carmen Andoh: 是的。
Mat Ryer: 不过 Go 是引导你转向 Windows 的"入门毒品"，你懂我的意思吧？（笑声）
Steve Francia: 从我的个人经验来看，其他动态语言和其他编程语言在 Windows 上都有点麻烦。而且我不是一个 Windows 的 Visual C++ 或者 .NET 程序员。所以当我使用那些更动态的开源语言时，总觉得是在跳过各种障碍，还会遇到别人从未遇到的边缘问题......而 Go 就非常顺畅。我可以在我的 Windows 机器上为所有的 Linux 和 Mac 做交叉编译......
Carmen Andoh: 你就像是 Windows 的行走广告牌。我们最好打电话给他们让他们来赞助我们......
Mat Ryer: 我不敢相信你刚才说它"就这么顺畅"。那可是 Apple 的口号。（笑声）
Steve Francia: 那是 Apple 的口号？
Mat Ryer: 是的，这是 Apple 的口号。
Steve Francia: 他们应该更好地实现这个口号。
Mat Ryer: 是啊。（笑声）
Jon Calhoun: 那你以前用过 Java 吗？
Steve Francia: 我整个职业生涯都在避免使用 Java。
Mat Ryer: 恭喜你。
Jon Calhoun: 好吧。我本来想说，Java 是少数几种我在不同操作系统上使用时没遇到太多问题的语言之一。
Steve Francia: 你是说在所有操作系统上都有相同的问题，对吧......
Jon Calhoun: 没错。（笑声）但这也是我在大学时学习 Java 的部分原因，它是我当时坚持使用的语言......不过后来我学了 Ruby，那简直糟透了。我在 Windows 上试了 Ruby，结果就是"不行，根本用不了"。
Mat Ryer: 是啊，我也是。Ruby 是我买 Mac 的原因。我买了 Mac 是为了能用 Ruby on Rails。不过我得说，Visual Studio 确实很棒，我认为它到现在仍然是做 C# 或 .NET 相关开发的最佳工具。Visual Studio 真的是太棒了......当然，VS Code 也是微软的产品，我觉得它现在仍然是 Mac 上 Go 开发者最常用的编辑器。
Jon Calhoun: 好吧，我们还有一点时间......你们想聊聊 Go.dev 的最后一个部分---学习模块吗？
Steve Francia: 我希望我们能聊到这个，因为这是 Carmen 的领域。
Carmen Andoh: 是我的领域吗？
Steve Francia: 噢，是的。
Carmen Andoh: 好吧......
Steve Francia: 而且这也是你们的领域。
Carmen Andoh: 这也是我的领域。今天我是既当嘉宾又当主持人。这感觉有点奇怪。Learn.go.dev---是的，我称它为 go.dev 中我最兴奋的部分，并且它是最适合社区合作、贡献和拥有的部分。当它最初推出时，有人反馈说"为什么我的网站/我的 YouTube 频道没有被收录？"对此，我的回答是"我们来谈谈吧。"因为我真的希望能把它做好。
我们在做这部分时，做了很多研究和工作，想弄清楚"如何让它更有用？"过程中发现，我们忽略了哪些人。我们发现的第一个群体是：零编程经验 的人。我们甚至不是从 Go 作为第二或第三语言开始的......所以我们与 Codeacademy 合作，来满足这一需求......意思是"我对编程一无所知，我想尝试 Go 作为我的第一门编程语言。"而这正是 Codeacademy 的强项，所以我们与他们的合作非常好。我可以分享的数据是，自从他们推出该课程并通过赞助免费提供以来，大概有70,000人参与了这个课程。
Steve Francia: 这是一个很大的数字，70,000 人。
Carmen Andoh: 确实如此。我之后会分享更多内容，不过是的......我每周都会收到相关的报告。整个课程有四个免费模块，整个课程一共有八个模块。你可以去 codeacademy.com 看看。
另一个我们发现的缺口是那些在公司工作的人的需求---他们因为某些原因觉得 Go 的官方教程（Tour of Go）或其他自学网站不适合他们，比如 Jon 的 Gophercises 以及其他资源......他们希望能直接获得解决问题的方案，比如"我该怎么用 Go 做 X？" 或者"为什么要从 Java 转到 Go？" 所以我们看了一下许多人在使用 Go 时的应用领域，或者说垂直领域，我们基于调查和其他研究数据选择了四个最常见的领域，并为这些特定的学习者提供了精心策划的学习路径，得到了非常好的反馈。大家都说"谢谢你一步步带我走过这些问题。"
我们发现有两种不同的心理模式在影响人们的接受度。如果你读过《跨越鸿沟》这本书，你会知道有早期采用者、早期多数、晚期采用者和晚期多数，而每一类人都有不同的心理特征。我们发现，早期采用者的心理是"我想要探索、学习，我需要一些空间来慢慢学习......" 而晚期多数采用者，通常是企业，他们的心理则是"直接告诉我怎么用 Go 实现。"
因此，策划这些学习路径的想法就是基于这些非常具体的需求，"我有一些事情想要做。" 我们2020年的计划是继续与更多社区合作，帮助那些现有资源不足以满足的人找到学习的空白点。我们希望保持免费，并确保覆盖所有不同的学习方式。因为我们发现，当你问十个人"你是怎么学习的？"时，你会得到十个不同的答案。学习的方式有很多种，我们希望提供各种学习方式，吸引更多的人。
最后一点是---这也涉及到我们之前提到的活动---当你和别人一起面对面学习时，学习效果是最好的。但这是非常难以实现的，我们希望能够利用线下聚会或在线聚会。面对面并不意味着我们必须坐在一起，它也可以是通过像 VS Code 这样的工具来进行协作编程，然后一起学习和测试......所以我们正在进一步研究这一点。
我问了很多人的意见......Jon 有一个学习网站，我曾经给 Jon 写过信。当时，我并不知道我是以 Go.dev 的身份在联系他，因为那个时候我们还没有公开这个项目......但我想听听大家的反馈；我一直在向很多人征求反馈，并且我会继续这样做，以便让 learn.go.dev 成为我们所期望的那种平台---一个由社区共同创造的高质量平台，能为各种学习者服务，吸引下一个两百万 Go 用户。
Jon Calhoun: 我能补充一点吗？从我的角度来看，这个网站让我兴奋的一点是，对于我来说，接触那些有语言障碍的人是非常困难的。比如说，他们可能不会说英语，或者需要视频的字幕之类的......作为独立创作者，这确实是一个挑战，但我知道随着 Go 语言的发展，很多人如果能用他们的母语学习，比如西班牙语，他们会学得更快......我很高兴看到有 Google 这样的公司做后盾---或者至少看起来有 Google 在背后支持---因为我觉得这为我们接触更大范围的受众打开了更多的门，对于像我这样的个人创作者来说，这通常是很难做到的。
Carmen Andoh: 国际化是我们的未来目标之一，而这也是我在一些大型会议上看到的一点。我们有一些像 Friends of Go 这样的公司，他们来自西班牙，他们写信告诉我们"嘿，我们有为西班牙语使用者提供的培训课程"，我们也有一些来自不同国家的培训师，比如印度、亚洲的一些地方以及欧洲，他们也表示"我们能合作吗？"
所以如果你想走得快，自己一个人走；如果你想走得远，那就一起走。所以 learn.go.dev 的宗旨就是积极寻求反馈，确保我们既有代表性，也能确保质量。
Mat Ryer: 是的，这很好。你认为这也会有社区的参与吗？它会一直是完全策划的吗？还是你们想过让用户投票的可能性呢？
Carmen Andoh: 我们对这个问题反复讨论过。有些人说"哦天啊，如果我们可以投票，那就会成为一种自我质量评估的方式。"问题是，所有东西都可以被操控......所以目前唯一不会被操控的就是我们可以信任的人，他们可以以道德标准来策划内容，并确保我们不断回顾和满足全球社区在学习方面的需求，无论是内容的缺失，还是学习方式的缺口，等等。
所以在可预见的未来，它仍将是(在不断)策划的。如果有一天我们能找到一种方法来进行投票，并且我们觉得它不会被操控，或者不会变成---你知道我最不想看到的就是有人说"去给我的内容投票吧，因为你是我的朋友"，而不是"去给我的内容投票吧，因为你真的从中学到了东西，或者你觉得它对你非常有帮助。"
但我们确实讨论过很多次。我记得在七月份的 GopherCon 上，我组织了一个工作组或圆桌讨论，来了大约15个人参加了两场讨论，其中有人真的很想推动这个投票的想法。我继续研究并考虑这个问题，最终决定"现在还不是时候"，直到我们能解决操控问题。
Mat Ryer: 是的。我的意思是，即使没有程序化的投票机制，社区依然有声音。在 Twitter 上有一个很好的 Go 社区，还有其他社区。当然，还有 Gopher 的 Slack......所以我觉得，虽然目前还没有正式的方式让大家分享想法和内容，但公开讨论确实在影响事情的发展。所以大家的意见当然是被听到的，因此如果有人想贡献意见，还是可以说出来的......
Carmen Andoh: 我也会的。我现在想要更多公开讨论的是，要让一个网站有用，你必须在两个相互对立的需求之间找到平衡。一个是保持全局视角，确保没有盲点；另一个是深入了解某一特定群体的实际需求。如何在这两个层次之间来回切换，这是一项非常具有挑战性的任务，也是我希望能够帮助解决的问题。
Steve Francia: Mat，你还提到了 Twitter 和 Gopher Slack......我们需要认识到，这个网站的目的是不是为了取代那些已经存在的优秀资源。所以我们说这是"由生态系统为生态系统服务"，但这并不意味着它会取代现有的生态系统解决方案。我们的初衷是填补我们看到的空白。它主要是一个策划网站，实际上是为了引用那些已经存在的资源。
当我听你描述投票机制时，它让我想起了 Reddit。我觉得 Reddit 频道很棒。我订阅了 Golang 的 Reddit 频道，我每天都会看。我总能看到一些好消息、新文章和新演讲，我觉得这是一个很好的机制，可以让大家的声音被听到......当然，还有你提到的其他资源。但如果你想要一个投票机制，我们已经有了。那就是 Reddit 的 r/golang。随时可以使用，它是一个非常好的资源。
Mat Ryer: 是的，太好了。另外还有 Go 的每周通讯，以及 Changelog 的通讯，它也是这个播客的家。如果有人想订阅这些......你真的可以通过这种方式一直了解最新的动态；这非常棒。
Jon Calhoun: 我想说，虽然 Reddit 和投票机制确实有些相似，但它们也有一些区别。Reddit 是实时的，或者说在某种程度上是时间限制的......而我觉得为学习资源投票可能会有一些价值，但我完全同意投票机制的复杂性，很难正确实现......所以我完全理解为什么你们现在不做这个。但我确实认为它和 Reddit 有点不同。虽然非常相似，但我见过很多情况，比如我有一些免费的资源，有人会在 Reddit 上发布，尽管它已经发布过了，但人们还是会说"我从来没见过这个"，这就说明，显然没人回去搜索这些内容，或者发生了什么别的事情......所以这里确实有一些差异。
Steve Francia: 还需要认识到，网站上的大部分内容是静态的。正如 Carmen 所说，我们讨论过做国际化；我们正在使用一个工具，它可以让我们实现国际化......虽然目前还没有计划这么做，但我们确保未来有机会再增加一些策划者，可能是来自不同地区的本地策划者，以帮助我们完成这一工作。
所以我们可能会在某种程度上开放它，得到社区的支持，同时保持严格的策划标准和高质量的要求。
Mat Ryer: 好吧，我想今天的时间差不多了。非常感谢我们的嘉宾 Julie Qiu、Steve Francia 以及我们的常驻嘉宾 Jon Calhoun 和 Carmen Andoh。我们下次 Go Time 再见！
Mat Ryer: 大家好，欢迎来到 Go Time！我是 Mat Ryer。今天我们要聊聊 Go.dev。它是一个用户友好的 Go 资源中心，提供策划好的资源，今天我们请到了它背后的两位大脑---Steve Francia（也叫 @spf13）和 Julie Qiu 来到我们的节目。大家好！
Steve Francia: 大家好！
Julie Qiu: 大家好！
Mat Ryer: 我们还有 Carmen Andoh 和 Jon Calhoun。你们好！
Carmen Andoh: 你好！
Mat Ryer: 最近怎么样？
Jon Calhoun: Mat，我觉得你有点撒谎了。我觉得 Carmen 也是 Go.dev 背后的一部分。
Steve Francia: 是的，其实我们有三位大脑。你只是比较常见到其中一位而已。
Carmen Andoh: 我是隐形的。我是隐形的。
Mat Ryer: 好吧，那我再说一遍。所以我们有三位 Go.dev 背后的大脑。
Steve Francia: 还有，应该是 Go.dev。
Mat Ryer: 好吧，Go.dev。这就是为什么我们要做这个。对于在听的朋友们来说，这就是节目的制作过程......（笑声）我得再来一次，让它听起来像是第一次说。这才是难点，你们都懂的......
Steve Francia: 是的，你不会说 GoogleCom 对吧。（笑声）
Jon Calhoun: 其实......（笑声）
Mat Ryer: Go.dev，好的。很聪明，因为它也是域名，对吧？
Steve Francia: 是的。
Mat Ryer: 明白了，谢谢。好的，那我们再来一次吧，大家不用担心，我不觉得尴尬。
Steve Francia: 顺便说一句，我觉得你刚才做得很棒。
Carmen Andoh: 我也是。
Steve Francia: 除了明显的错误，其他都做得非常好。
Mat Ryer: （笑）是啊......好吧，这就是为什么我们要做迭代开发。