有四分之一的 Gopher 已经泛型了

在本文中，我们将通过一系列图表来解读此番调查。所有图表均采用相同格式，标题部分是向受访者们提出的具体问题。 除非另有说明，否则各问题均为单选形式，受访者只能选择其一。图表的副标题部分，会标注是否为多选问题或开放性问题。对于开放性问题，Go 团队成员认真阅读并手动整理了受访者们的意见。大家对于这类问题的回应多种多样，因此我们挑选了最具共性的前十大主题，其余主题则被归类为“其他”。

为了帮助大家了解每条结论的证据权重，我们使用误差线来表示响应意见的 95% 置信区间：条形较窄，则表示信心越强。有时，可能有多条响应意见的误差线彼此重叠，意味着这些响应的相对顺序并不具备统计学意义（或者说这些意见之间相互绑定）。各图表的右下角为图表中受访者者人数，形式为“n= 受访者人数”。

支持类型参数（即泛型）的 Go 1.18 发布之后，我们希望大家如何看待和采用这项新功能，并确定使用泛型时的常见挑战或障碍。

绝大多数受访者（86%）都知道 Go 1.18 版本引入了泛型。虽然我们预计这个比例会超过一半，但没想到有这么高。我们还发现，约四分之一受访者已经开始在 Go 代码中使用泛型（26%），其中 14% 表示是在生产或已发布的代码中使用。 大多数受访者（54%）并不抵触泛型，只是目前还没开始使用。** 另有 8% 的受访者有意在 Go 中使用泛型，但出于种种原因而暂未行动。

是什么阻止了一些开发人员使用泛型？困扰大多数受访者的其实就两个理由：首先，30% 的受访者表示他们发现现有泛型实现仍有诸多限制，例如不支持参数化方法、类型推断和类型切换等。受访者表示，这些问题限制了泛型的可用空间，或者导致泛型代码过于冗长。

第二个理由则是某些依赖项尚不支持泛型——其中最典型的例子是 linter，此外还有仍在使用的早期 Go 版本，或者尚不提供 Go 1.18 包（26%）的 Linux 发行版等。12% 的受访者则是因为学习曲线陡峭或说明文档不充分而选择放弃。除了这些重要因素，受访者还反馈了一些相对不太常见、但仍有意见的阻碍，如下图所示。这里，我们仅列出已经在使用泛型，或者曾尝试使用泛型但未能成功的受访者。

我们还询问了尝试用过泛型的受访者，希望了解他们的感受。令人振奋的是，10% 的受访者表示泛型确实简化了自己的代码、降低了代码重复度。除了高度赞赏之外，其他受访者也普遍（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 文件更新间接依赖项的难度较高等。我们也询问了一般使用哪种调查方式了解漏洞影响或探究根本原因，这 12% 愿意做进一步调查的受访者们给出了更积极的答案：其中 70% 对漏洞的潜在影响进行了调查，并发现这才是整个过程中最困难的部分。除了调查本身的难度，他们还提到这项工作通常不在项目计划之内，而且完全没有直接回报。

Go 团队认为，这种深入调查应用程序中各依赖项安全态势的好习惯，将直接决定漏洞可能给组织带来的实际风险、甚至是否发生数据泄露。因此，我们设计出 govulncheck，在调用的函数中存在漏洞时向开发者发出提醒，并列出该函数在代码中的确切位置。希望这款工具能帮助开发者快速对应用程序中的致命漏洞进行调查，减少计划外的安全工作负担。

下面，我们又询问了关于工具体验的问题：

• 自上次调查以来，编辑环境是否发生了变化？

• 开发者愿意使用工作区吗？如果愿意，在初上手时感觉有哪些不便？

• 开发者如何处理内部包文档？

VS Code 在受访者中的人气似乎还在持续增长。自 2021 年以来，受访者就将其选为最受欢迎的 GO 代码编辑器，今年的支持比例更是从 42% 上升至 45%。VS Code 和 GoLand 两大高人气编辑器似乎不受组织规模的影响，在大企业和小公司里都很受欢迎。但从统计结果来看，业余开发者似乎更偏爱 VS Code。

在 2021 年通过 gopls 语言服务器强化 VS Code 的 Go 支持能力之后，Go 团队一直想了解 gopls 中存在哪些使用痛点。虽然我们已经从开发者那边收到了不少反馈，但不清楚会不会有很多开发者直接禁用掉了这项功能。为了收集关于 gopls 的负面意见，我们专门统计了那些所使用的编辑器能够支持 gopls 的受访者（无论他们是否实际使用 gopls），并发现禁用比例只有 2%。而且在 VS Code 上，禁用比例更是下降至 1%。这让我们对 gopls 的表现更具信心，也期待大家在 GitHub 上提交更多关于 gopls 的问题。

在工作区这边，很多受访者似乎是在本次调查中才知道 Go 能够支持多模块工作区。对 VS Code 用户的随机调查显示，大多数受访者从来就没听说过工作区（在随机抽样受访者中占比 53%，在自荐受访者中占比 33%）。其实对泛型的认知和接纳差异在这两个受访者群体间也体现得非常明显，分别为 93% 和 68%。也许是因为我们目前的 Go 博客或社交媒体渠道还不足以涵盖足够的 Go 开发者，所以很多新功能并不能有效传递至用户耳中。

我们还发现，有 9% 的受访者曾经试用过工作区，另有 5% 表示想要尝试但最终未能进行。关于使用 Go 工作区的阻碍，位居榜首的是 go work 命令缺乏说明文档和有意义的错误消息（21%），其次则是要求重构现有 repo（13%）。与安全部分的讨论类似，同样有不少受访者给出了“没时间 / 不是优先事项”之类的理由。按照我们的理解，这意味着跟实际带来的收益相比，工作区的理解和设置门槛仍然偏高，也可能是开发者之前就已经找到了自己的解决办法。

在 Go 模块发布之前，不少组织已经在通过内部文档服务器（例如支持 godoc.org 的服务器）为员工提供内部 Go 包文档。但现在，这类服务器的设置流程比以往更为复杂，我们也在考虑要不要投资来简化这个过程。因此，我们询问受访者如何查看内部 Go 模块文档，想了解这是不是他们的首选工作方式。

结果显示，目前最常见的内部 Go 文档查看方式是阅读代码（81%），其中约半数觉得这样就挺好，但也有 39% 认为能有内部文档服务器就更好了。我们还询问了这类服务器应该由谁配置和维护，有三分之二的受访者认为应该是软件工程师，余下三分之一觉得可以指派专门的 IT 支持或运营人员。从这个角度看，理想的文档服务器应该是那种交钥匙解决方案，或者至少不会带来过多的额外工作负担（一个人在午休时间就能维护好）。考虑到目前开发人才严重短缺的现实，这样的要求完全在情理之中。

总体而言，自 2021 年的调查以来，受访者群体的基本特征并没有太大变化。部分受访者（53%）拥有两年及以上 Go 使用经验，其余受访者则是 Go 社区中的新人。约三分之一受访者来自小型企业（员工少于 100 人），四分之一来自中型企业（100 至 1000 名员工），四分之一来自大型企业（员工超过 1000 人）。与去年类似，我们发现 VS Code 上的调查弹窗吸引到了不少北美和欧洲以外地区的开发者。

受访者使用 Go 语言的具体方式跟上年相比，同样没有出现什么统计意义上的差异。最常见的两大用例仍然是构建 API/RPC 服务（73%）和编写 CLI（60%）。我们使用线性模型，尝试调查受访者使用 Go 的时间与他们的开发方向之间是否存在关联。我们发现，Go 经验不足一年的受访者一般更关注 GUI、物联网、游戏、机器学习 /AI 或移动应用等开发目标。而一年以上受访者则明显较少用 Go 语言进行这些领域的开发，说明他们可能是在实践当中遇到了重大障碍。

大多数受访者会在 Linux（59%）或 macOS（52%）上进行 Go 开发，而部署目的地则绝大多数是 Linux 系统（93%）。在本次调查中，我们新增了在 Windows Subsystem for Linux（WSL）上进行 Go 开发的选项，并发现有 13% 的受访者选择了这种方式。

最后，我们询问了受访者过去一年来对 Go 的总体使用感受，特别是使用 Go 时遇到过的最大挑战。我们发现，93% 的受访者表示“还行”（30%）或非常满意（63%），基本与 2021 年调查得到的 92% 持平。

多年以来，泛型一直是 Go 开发中的争议焦点。Go 1.18 对类型参数的支持虽然缓和了旧矛盾，但又带来了错误处理这个新问题。可以肯定的是，错误处理不是孤立存在的，与库缺失或不够成熟、开发者学习难度大、最佳实践不易实施、对类型系统的其他修订（例如支持枚举及更多函数式编程语法）等其他问题密切相关。总之，除了泛型之外，Go 开发者还需要面对坎坷的前进道路。

本次 Go 开发者调查主要侧重于 Go 1.18 版本中的新功能。我们发现泛型的普及正在稳步推进，但开发者也遇到了当前实现中的不少限制。模糊测试和工作区的普及率仍然有限，但核心并非技术原因：要想扩大受众，这两项功能首先需要解决什么时候用、怎么用的问题。另一个阻碍则是开发者没工夫关注这些新特性，这一点在安全开发方面也有体现。根据这些结论，Go 团队将确定下一步工作的优先级，并影响到未来的工具设计思路。

感谢大家关注此次 Go 开发者研究，希望我们公布的结果能给您带来一点启发。更要感谢参与调查并积极回复我们的 Go 开发者，这些反馈将帮助我们了解 Go 的当前局限和现实挑战，据此改善整个生态系统。我们也会再接再厉，争取不断将更完善的 Go 版本交付到大家手中！

原文链接：https://go.dev/blog/survey2022-q2-results

推荐阅读

• 万字长文告诉你Go 1.19中值得关注的几个变化