Go 博客

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

Todd Kulesza
2022 年 9 月 8 日

概述

本文分享了 2022 年 6 月 Go 开发者调查的结果。我谨代表 Go 团队，感谢 5,752 位参与调查并分享他们在 Go 1.18 中使用新功能（包括泛型、安全工具和工作区）的经验的人。你们帮助我们更好地理解开发者如何发现和使用这些功能，正如本文将讨论的那样，提供了有用的见解，以便进一步改进。谢谢大家！ 💙

主要发现

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

如何解读这些结果

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

为了帮助读者理解每个发现所依据的证据权重，我们包含了显示响应 95% 置信区间的误差条；误差条越窄表示信心越高。有时两个或多个响应的误差条会重叠，这意味着这些响应的相对顺序在统计上没有意义（即，这些响应实际上是并列的）。每个图表的右下角显示了包含在图表中的受访者人数，形式为“n = [受访者人数]”。

关于方法论的说明

大多数受访者是“自愿参与”调查的，这意味着他们是在Go 博客、Twitter 上的 @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% 的受访者表示他们遇到了当前泛型实现的限制，例如希望有参数化方法、改进的类型推断或基于类型的 switch。受访者表示这些问题限制了泛型的潜在用例，或觉得它们使泛型代码过于冗长。第二类涉及依赖尚不支持泛型的工具——linters 是最常见的阻碍采用的工具，但此列表也包括诸如组织仍在使用较早的 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 在受访者中的受欢迎程度似乎持续增长，表示它是 Go 代码首选编辑器的受访者比例从 2021 年的 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 上提交 issue 的方式告知我们。

关于工作区，似乎许多人是通过本次调查首次了解到 Go 对多模块工作区的支持。通过 VS Code 随机提示了解到本次调查的受访者尤其可能表示他们之前从未听说过工作区（随机抽样的受访者中有 53%，自愿参与的受访者中有 33%），我们在对泛型的认知上也观察到了类似的趋势（尽管这两个群体中的认知度都更高，自愿参与的受访者中有 93% 知道 Go 1.18 中包含了泛型，而随机抽样的受访者中有 68%）。一种解释是，目前我们无法通过 Go 博客或现有社交媒体渠道触及大量 Go 开发者，而这些渠道传统上是我们分享新功能的主要机制。

我们发现 9% 的受访者表示他们尝试过工作区，另有 5% 的受访者表示想使用但受到阻碍。受访者讨论了在使用 Go 工作区时遇到的各种挑战。缺乏文档和 go work 命令没有提供有用的错误消息排在首位（21%），其次是技术挑战，例如重构现有仓库（13%）。与安全性部分讨论的挑战类似，我们再次看到列表中的“缺乏时间/非优先级”——我们将其解读为，相对于工作区提供的优势而言，理解和设置工作区的门槛仍然有点高，这可能是因为开发者已经有了替代解决方案。

在 Go modules 发布之前，组织可以运行内部文档服务器（例如为 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、IoT、游戏、ML/AI 或移动应用），这表明在这些领域中使用 Go 存在兴趣，但一年经验后出现的下降也意味着开发者在这些领域使用 Go 时遇到了重大障碍。

大多数受访者在使用 Go 进行开发时使用 Linux (59%) 或 macOS (52%)，绝大多数部署到 Linux 系统 (93%)。本轮调查我们新增了在适用于 Linux 的 Windows 子系统 (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 秒）或倾向于勾选多选问题所有选项的受访者数据。最终保留了 5,752 份回复。

大约三分之一的受访者来自随机抽样的 VS Code 提示，这组受访者往往比通过 Go 博客或 Go 社交媒体渠道找到调查的人拥有更少的 Go 经验。我们使用线性模型和逻辑模型来调查这些群体之间的明显差异是否能更好地用经验差异来解释，通常情况确实如此。文本中注明了例外情况。

今年我们非常希望也能像 Stack Overflow、JetBrains 等其他开发者调查一样，与社区分享原始数据集。不幸的是，最近的法律指导目前阻止我们这样做，但我们正在为此努力，并预计在下次 Go 开发者调查时能够分享原始数据集。

结论

本次 Go 开发者调查聚焦于 Go 1.18 版本中的新功能。我们发现泛型的采用进展顺利，开发者已经遇到了一些当前实现的限制。模糊测试和工作区的采用速度较慢，尽管主要原因并非技术性：这两者的主要挑战在于理解何时以及如何使用它们。开发者缺乏时间专注于这些主题是另一个挑战，这个主题也延伸到了安全工具。这些发现正在帮助 Go 团队确定下一步工作的优先级，并将影响我们未来工具的设计方式。

感谢您与我们一同回顾 Go 开发者研究——希望这些内容富有洞察力且引人入胜。最重要的是，感谢多年来所有参与我们调查的每一个人。您的反馈帮助我们理解 Go 开发者所面临的限制，并识别他们遇到的挑战。通过分享这些经验，您正在帮助改进 Go 生态系统，造福所有人。谨代表全球所有的 Gopher，我们感谢您！ 🎉