Go 博客

Go 开发者调查 2022 年第二季度结果

Todd Kulesza
2022 年 9 月 8 日

概述

本文分享了 2022 年 6 月版 Go 开发者调查的结果。代表 Go 团队，感谢 5752 位参与者告诉我们他们使用 Go 1.18 中引入的新功能（包括泛型、安全工具和工作区）的体验。你们帮助我们更好地了解开发者如何发现和使用这些功能，并且正如本文将讨论的那样，为进一步改进提供了宝贵的见解。谢谢！💙

主要发现

• 泛型的采用速度很快。绝大多数受访者都意识到 Go 1.18 版本中包含了泛型，大约四分之一的受访者表示他们已经开始在 Go 代码中使用泛型。与泛型相关的最常见的反馈是“谢谢！”，但很明显开发者已经遇到了一些初始泛型实现的局限性。
• 模糊测试对大多数 Go 开发者来说是新的。Go 内置模糊测试的认知度远低于泛型，受访者对为什么或何时考虑使用模糊测试存在更多的不确定性。
• 第三方依赖项是首要的安全问题。避免使用存在已知漏洞的依赖项是受访者面临的首要安全挑战。更广泛地说，安全工作通常是计划外的且得不到回报的，这意味着工具需要尊重开发者的工作时间和注意力。
• 在发布新功能时，我们可以做得更好。随机抽取的参与者不太可能了解最近的 Go 工具版本，而通过 Go 博客找到调查问卷的人则了解得更多。这表明我们应该寻求超越博客文章来传达 Go 生态系统中的变化，或者扩大努力更广泛地分享这些文章。
• 错误处理仍然是一个挑战。在泛型发布后，受访者在使用 Go 时面临的首要挑战变成了错误处理。然而，总体而言，对 Go 的满意度仍然很高，我们发现受访者使用 Go 的方式没有发生重大变化。

如何解读这些结果

在本文中，我们使用调查回复图表来为我们的发现提供支持证据。所有这些图表都使用类似的格式。标题是调查受访者看到的准确问题。除非另有说明，否则问题为多选题，参与者只能选择一个回复选项；每个图表的副标题会告诉您问题是否允许选择多个回复选项，或者是否为开放式文本框而不是多选题。对于开放式文本回复的图表，Go 团队成员阅读并手动分类了所有回复。许多开放式问题引起了各种各样的回复；为了使图表大小合理，我们将它们压缩到最多前 10 个主题，其他主题都归类为“其他”。

为了帮助读者理解每个发现背后的证据权重，我们包含了显示回复 95% 置信区间的误差条；误差条越窄，表示置信度越高。有时两个或多个回复的误差条重叠，这意味着这些回复的相对顺序在统计上没有意义（即，回复实际上是平局）。每个图表的右下方显示了包含在图表中的回复人数，格式为“n = [回复人数]”。

关于方法论的说明

大多数调查受访者“自行选择”参加调查，这意味着他们在Go 博客、@golang 推特或其他 Go 社交渠道上发现了调查问卷。这种方法的一个潜在问题是，不关注这些渠道的人不太可能了解调查问卷，并且他们的回复可能与密切关注这些渠道的人不同。大约三分之一的受访者是随机抽取的，这意味着他们在 VS Code 中看到调查提示后回复了问卷（2022 年 6 月 1 日至 6 月 21 日期间，所有使用 VS Code Go 插件的用户都有 10% 的概率收到此随机提示）。这个随机抽取的群体帮助我们将这些发现推广到更广泛的 Go 开发者社区。大多数调查问题在这两个群体之间没有显示出有意义的差异，但在少数存在重要差异的情况下，读者将看到按“随机样本”和“自行选择”群体细分的图表。

泛型

在 Go 1.18 发布并支持类型参数（更常见地称为泛型）后，我们希望了解泛型的初始认知度和采用情况，以及识别使用泛型的常见挑战或障碍。

绝大多数调查受访者（86%）已经意识到泛型作为 Go 1.18 版本的一部分发布。我们希望看到这里有一个简单的多数，所以这比我们预期的认知度要高得多。我们还发现，大约四分之一的受访者已开始在 Go 代码中使用泛型（26%），其中包括 14% 的人表示他们已经在生产或发布的代码中使用泛型。大多数受访者（54%）不反对使用泛型，但目前没有需求。我们还发现 8% 的受访者想要在 Go 中使用泛型，但目前受到某些因素的阻碍。

是什么阻碍了一些开发者使用泛型？大多数受访者属于以下两类之一。首先，30% 的受访者表示他们遇到了当前泛型实现的限制，例如需要参数化方法、改进类型推断或根据类型进行切换。受访者表示这些问题限制了泛型的潜在用例，或者认为它们使泛型代码变得不必要地冗长。第二类涉及依赖于尚不支持泛型的某些内容——linter 是阻止采用泛型的最常见工具，但这其中还包括组织仍然使用早期 Go 版本或依赖于尚未提供 Go 1.18 软件包的 Linux 发行版（26%）。12% 的受访者提到了陡峭的学习曲线或缺乏有用的文档。除了这些主要问题之外，受访者还告诉我们各种不太常见（尽管仍然有意义）的挑战，如下面的图表所示。为了避免关注假设，此分析仅包括表示自己已经使用过泛型或尝试使用过泛型但受到阻碍的人。

我们还询问了尝试使用过泛型的调查受访者是否还有其他反馈。令人鼓舞的是，十分之一的受访者表示泛型已经简化了他们的代码，或者减少了代码重复。最常见的回复是“谢谢！”或一般的正面情绪的某种变体（43%）；相比之下，只有 6% 的受访者表达了负面反应或情绪。与上述“最大挑战”问题的发现相呼应，近三分之一的受访者讨论了遇到 Go 泛型实现的限制。Go 团队正在利用这组结果来帮助决定是否或如何放松其中一些限制。

安全

继2020 年 SolarWinds 漏洞事件之后，安全地开发软件的做法再次受到关注。Go 团队优先考虑了这方面的工作，包括创建软件物料清单 (SBOM)、模糊测试以及最近的漏洞扫描工具。为了支持这些工作，本次调查提出了几个关于软件开发安全实践和挑战的问题。我们特别希望了解

• Go 开发者今天正在使用哪些类型的安全工具？
• Go 开发者如何发现和解决漏洞？
• 编写安全的 Go 软件面临的最大挑战是什么？

我们的结果表明，虽然静态分析工具被广泛使用（65% 的受访者），但只有一小部分受访者目前使用它来查找漏洞（35%）或以其他方式改进代码安全性（33%）。受访者表示，安全工具最常在 CI/CD 期间运行（84%），少数受访者表示开发人员在开发过程中本地运行这些工具（22%）。这与我们团队进行的其他安全研究结果一致，该研究发现，在 CI/CD 期间进行安全扫描是理想的后备方案，但开发人员通常认为这对于首次通知来说太晚了：他们希望在构建依赖项之前就知道依赖项可能存在漏洞，或者验证版本更新是否解决了漏洞，而无需等待 CI 对他们的 PR 运行完整的附加测试。

我们还询问了受访者在开发安全软件方面面临的最大挑战。最普遍的困难是评估第三方库的安全性（57% 的受访者），漏洞扫描程序（例如 GitHub 的 dependabot 或 Go 团队的 govulncheck）可以帮助解决此问题。其他主要挑战表明了对更多安全工具的需求：受访者表示，在编写代码时很难始终如一地应用最佳实践，以及验证生成的代码是否没有漏洞。

模糊测试是另一种提高应用程序安全性的方法，对于大多数受访者来说，它仍然是一个比较新的概念。只有 12% 的人表示他们在工作中使用它，5% 的人表示他们采用了 Go 内置的模糊测试工具。一个开放式后续问题询问是什么导致模糊测试难以使用，发现主要原因不是技术问题：前三个回复讨论了不了解如何使用模糊测试（23%）、缺乏时间用于模糊测试或更广泛的安全方面（22%），以及理解开发人员为什么要以及何时可能想要使用模糊测试（14%）。这些发现表明，我们在传达模糊测试的价值、应该模糊测试什么以及如何将其应用于各种不同的代码库方面仍有工作要做。

为了更好地了解漏洞检测和解决方面的常见任务，我们询问了受访者在过去一年中是否了解了他们 Go 代码或其依赖项中的任何漏洞。对于那些了解漏洞的人，我们随后询问了他们是如何发现最近的漏洞、如何调查和/或解决它，以及整个过程中最具挑战性的部分。

首先，我们发现有证据表明漏洞扫描是有效的。四分之一的受访者表示他们了解了其第三方依赖项之一中的漏洞。但是，请记住，只有大约三分之一的受访者使用了漏洞扫描——当我们查看那些表示运行某种漏洞扫描程序的受访者的回复时，这一比例几乎翻倍，从 25% → 46%。除了依赖项或 Go 本身中的漏洞外，12% 的受访者表示他们了解了他们自己代码中的漏洞。

大多数受访者表示他们通过安全扫描程序了解了漏洞（65%）。受访者提到的最常见的工具是 GitHub 的 dependabot（38%），使其比所有其他漏洞扫描程序（27%）的引用频率更高。在扫描工具之后，了解漏洞的最常见方法是公开报告，例如发行说明和 CVE（22%）。

一旦受访者了解了漏洞，最常见的解决方案是升级有漏洞的依赖项（67%）。在也讨论过使用漏洞扫描程序的受访者中（作为讨论第三方依赖项中漏洞的参与者的代理），这一比例上升到 85%。不到三分之一的受访者讨论过阅读 CVE 或漏洞报告（31%），只有 12% 的人提到了更深入的调查以了解他们的软件是否（以及如何）受到漏洞的影响。

只有 12% 的受访者表示他们对漏洞在其代码中是否可达或其可能对服务产生的潜在影响进行了调查，这一点令人惊讶。为了更好地理解这一点，我们还查看了受访者认为应对安全漏洞最具挑战性的部分。他们以大致相同的比例描述了几个不同的主题，从确保依赖项更新不会破坏任何内容到了解如何通过 go.mod 文件更新间接依赖项。此列表中也包含了解漏洞影响或根本原因所需的调查类型。但是，当我们只关注那些表示进行了这些调查的受访者时，我们发现了一个明显的相关性：70% 表示对漏洞的潜在影响进行了调查的受访者认为这是此过程中最具挑战性的部分。原因不仅包括任务的难度，还包括它通常是计划外且没有奖励的工作这一事实。

Go 团队认为，这些更深入的调查（需要了解应用程序如何使用有漏洞的依赖项）对于理解漏洞可能对组织造成的风险以及是否发生了数据泄露或其他安全问题至关重要。因此，我们设计了 govulncheck，只在调用漏洞时提醒开发人员，并将开发人员引导至其代码中使用有漏洞函数的确切位置。我们希望这将使开发人员更容易快速调查对他们的应用程序真正重要的漏洞，从而减少此领域中计划外工作的总量。

工具

接下来，我们调查了三个与工具相关的重点问题

• 自上次调查以来，编辑器格局是否发生了变化？
• 开发人员是否使用工作区？如果是，他们在开始使用时遇到了哪些挑战？
• 开发人员如何处理内部包文档？

VS Code 似乎在受访者中越来越受欢迎，自 2021 年以来，表示它是他们首选 Go 代码编辑器的受访者比例从 42% → 45% 上升。VS Code 和 GoLand 是两个最受欢迎的编辑器，在小型和大型组织之间没有显示出受欢迎程度的差异，尽管业余爱好者开发人员更有可能偏爱 VS Code 而不是 GoLand。此分析不包括随机抽样的 VS Code 受访者——我们预计我们邀请参与调查的人会表现出对用于分发邀请的工具的偏好，这正是我们看到的（91% 的随机抽样的受访者偏爱 VS Code）。

继 2021 年切换到 通过 gopls 语言服务器增强 VS Code 的 Go 支持 之后，Go 团队一直对了解与 gopls 相关的开发人员痛点感兴趣。虽然我们从当前使用 gopls 的开发人员那里收到了大量反馈，但我们想知道是否很大一部分开发人员在发布后不久就禁用了它，这可能意味着我们没有听到关于特别有问题的用例的反馈。为了回答这个问题，我们询问了那些表示他们更喜欢支持 gopls 的编辑器的受访者他们是否使用了 gopls，发现只有 2% 的人表示他们禁用了它；对于 VS Code 而言，这一比例下降到 1%。这增强了我们对正在从具有代表性的开发人员群体那里听到反馈的信心。对于仍然存在 gopls 未解决问题的读者，请通过 在 GitHub 上提交问题 告知我们。

关于工作区，似乎许多人是从本次调查中首次了解 Go 对多模块工作区的支持。通过 VS Code 的随机提示了解调查的受访者尤其可能表示他们以前从未听说过工作区（53% 的随机抽样的受访者 vs. 33% 的自主选择的受访者），我们在泛型的意识方面也观察到了这种趋势（尽管这两组的比例都更高，93% 的自主选择的受访者知道泛型已在 Go 1.18 中推出，而 68% 的随机抽样的受访者知道）。一种解释是，存在一大批 Go 开发人员，我们目前无法通过 Go 博客或现有的社交媒体渠道接触到他们，而这些渠道历来是我们分享新功能的主要机制。

我们发现 9% 的受访者表示他们尝试过工作区，另外 5% 的人希望尝试但被某些因素阻碍。受访者在尝试使用 Go 工作区时讨论了各种挑战。go work 命令缺乏文档和有帮助的错误消息位居榜首（21%），其次是重构现有存储库等技术挑战（13%）。与安全部分中讨论的挑战类似，我们再次看到“时间不足/不是优先事项”出现在此列表中——我们将其解释为理解和设置工作区的门槛与它们提供的益处相比仍然有点高，这可能是因为开发人员已经有了变通方案。

在 Go 模块发布之前，组织能够运行内部文档服务器（例如 为 godoc.org 提供支持的那个服务器）为员工提供私有内部 Go 包的文档。对于 pkg.go.dev 来说，情况仍然如此，但设置此类服务器比以前更复杂。为了了解我们是否应该投资于简化此过程，我们询问了受访者他们今天如何看待内部 Go 模块的文档，以及这是否是他们首选的工作方式。

结果显示，如今查看内部 Go 文档的最常见方式是阅读代码（81%），虽然大约一半的受访者对此感到满意，但很大一部分人更希望拥有一个内部文档服务器（39%）。我们还询问了谁最有可能配置和维护此类服务器：受访者以 2 比 1 的比例认为这将是软件工程师而不是来自专门的 IT 支持或运维团队的人员。这强烈表明，文档服务器应该是一个交钥匙解决方案，或者至少对于单个开发人员来说很容易快速启动（例如，在午休时间），因为这种类型的工作只是开发人员已经满负荷的工作中的又一项责任。

我们收到的反馈来源

总体而言，自 我们 2021 年的调查 以来，受访者的总体人口统计和企业统计数据没有发生实质性变化。大多数受访者（53%）使用 Go 的经验至少两年，其余则对 Go 社区较新。大约三分之一的受访者在小型企业（< 100 名员工）工作，四分之一在中型企业（100 – 1,000 名员工）工作，四分之一在大型企业（> 1,000 名员工）工作。与去年类似，我们发现我们的 VS Code 提示有助于鼓励北美和欧洲以外地区的调查参与。

受访者如何使用 Go

与上一节类似，我们没有发现受访者使用 Go 的方式在年度同比变化方面有任何统计学意义上的差异。两种最常见的用例仍然是构建 API/RPC 服务（73%）和编写 CLI（60%）。我们使用线性模型来调查受访者使用 Go 的时间长短与其使用 Go 构建的内容类型之间是否存在关系。我们发现，使用 Go 经验少于 1 年的受访者更有可能构建此图表下半部分的内容（GUI、物联网、游戏、机器学习/人工智能或移动应用），这表明人们对在这些领域使用 Go 感兴趣，但一年后使用经验下降也暗示开发人员在这些领域使用 Go 时遇到了重大障碍。

大多数受访者在使用 Go 开发时使用 Linux（59%）或 macOS（52%），并且绝大多数部署到 Linux 系统（93%）。在本轮调查中，我们添加了一个在 Windows Subsystem for Linux (WSL) 上开发的选项，发现 13% 的受访者在使用 Go 时使用此选项。

情绪和挑战

最后，我们询问了受访者在过去一年中对 Go 的整体满意度或不满程度，以及他们在使用 Go 时面临的最大挑战。我们发现，93% 的受访者表示他们“有点”（30%）或“非常”（63%）满意，这与 2021 年 Go 开发者调查中 92% 的受访者表示满意没有统计学上的差异。

多年来，泛型一直是使用 Go 时最常讨论的挑战，Go 1.18 中对类型参数的支持最终导致了一个新的首要挑战：我们老朋友，错误处理。需要明确的是，错误处理在统计上与其他一些挑战相关，包括某些领域缺少或不成熟的库、帮助开发人员学习和实施最佳实践，以及类型系统的其他修订，例如对枚举或更多函数式编程语法的支持。泛型出现后，Go 开发人员似乎面临着非常多的挑战。

调查方法

我们于 2022 年 6 月 1 日通过 go.dev/blog 和 Twitter 上的 @golang 公开发布了这项调查。我们还在 6 月 1 日至 21 日期间，通过 Go 插件随机提示了 10% 的 VS Code 用户参与调查。调查于 6 月 22 日结束，并记录了部分回复（即开始但未完成调查的人）。我们过滤掉了那些特别快速（< 30 秒）完成调查或倾向于在多选题中选择所有选项的受访者的数据。最终得到 5752 份回复。

大约三分之一的受访者来自随机的 VS Code 提示，并且与通过 Go 博客或 Go 的社交媒体渠道找到调查的人相比，这部分人往往使用 Go 的经验较少。我们使用线性模型和逻辑回归模型来调查这些组之间明显的差异是否可以通过这种经验差异更好地解释，通常情况是这样的。例外情况在文本中进行了说明。

今年，我们非常希望能够与社区共享原始数据集，类似于来自 Stack Overflow、JetBrains 等其他开发者调查。但最近的法律建议不幸地阻止了我们目前这样做，但我们正在努力解决这个问题，并期望能够在下一轮 Go 开发者调查中共享原始数据集。

结论

本次 Go 开发者调查重点关注 Go 1.18 版本的新功能。我们发现泛型的采用正在稳步进行，开发人员已经遇到了一些当前实现的局限性。模糊测试和工作区的使用率增长较慢，但这主要不是出于技术原因：两者面临的主要挑战都是理解何时以及如何使用它们。开发人员缺乏时间来关注这些主题也是一个挑战，并且这一主题也延续到了安全工具中。这些发现正在帮助 Go 团队确定我们的下一步工作重点，并将影响我们如何设计未来的工具。

感谢您与我们一起了解 Go 开发者研究之旅——我们希望它能提供有益的见解。最重要的是，感谢多年来所有回复我们调查的人。您的反馈帮助我们了解 Go 开发人员的工作限制并识别他们面临的挑战。通过分享这些经验，您正在帮助改善所有人的 Go 生态系统。代表所有 Gophers，我们感谢您！