2021-03-09 2020 开发人员调查结果

:::info 日期：2021 年 03 月 09 日
作者：Alice Merrick
原文链接：https://go.dev/blog/survey2020-results :::

感谢大家的反馈

在 2020 年，我们再次获得了 9,648 条回复，与 2019 年一样多。感谢您抽出宝贵时间向社区提供有关您使用 Go 的体验的这些见解！

新的模块化设计

您可能会注意到有些问题的样本量（“n=”）比其他问题小。这是因为有些问题会向所有人展示，而另一些则只向一部分随机受访者展示。

重点

• Go 在工作场所和企业中的使用正在扩大，76% 的受访者在工作中使用 Go，66% 的受访者表示 Go 对其公司的成功至关重要
• 总体满意度很高，92% 的受访者对使用 Go 感到满意
• 大多数受访者认为在不到 3 个月的时间内使用 Go 很有成效，81% 的人认为使用 Go 非常有成效
• 受访者表示会及时升级到最新的 Go 版本，前 5 个月的比例为 76%
• 使用 pkg.go.dev 的受访者（91%）比非用户（82%）更能成功地找到 Go 软件包
• Go 模块的采用几乎是普遍的，满意度为 77%，但受访者也强调需要改进文档
• Go 继续大量用于 API、CLI、Web、DevOps 和数据处理
• 代表性不足的群体在社区中往往不那么受欢迎

我们是从谁那里了解到 Go?

人口统计问题帮助我们区分哪些年同比差异可能是由响应调查的人的变化与情绪或行为的变化引起的。 由于我们的人口统计数据与去年相似，因此我们有理由相信其他同比变化并非主要是由于人口结构变化所致。

例如，从 2019 年到 2020 年，组织规模、开发人员经验和行业的分布基本保持不变。



几乎一半 (48%) 的受访者使用 Go 的时间不到两年。 2020 年，使用 Go 不到一年的人对我们的回复较少。

大多数人表示他们在工作中 (76%) 和工作之外 (62%) 使用 Go。 在工作中使用 Go 的受访者比例逐年上升。

今年我们引入了一个关于主要工作职责的新问题。 我们发现 70% 的受访者的主要职责是开发软件和应用程序，但极少数 (10%) 负责设计 IT 系统和架构。
与前几年一样，我们发现大多数受访者并不是 Go 开源项目的频繁贡献者，75% 的人表示他们“很少”或“从不”这样做。

开发者工具和实践

与前几年一样，绝大多数受访者表示在 Linux (63%) 和 macOS (55%) 系统上使用 Go。 随着时间的推移，主要在 Linux 上开发的受访者比例似乎略有下降。
编辑器偏好似乎首次稳定下来：VS Code 仍然是最受欢迎的编辑器（41%），GoLand 位居第二（35%）。 这些编辑加起来占回复的 76%，其他偏好没有像往年那样继续减少。

今年，我们要求受访者根据他们假设有 100 个“GopherCoins”（一种虚构货币）会花多少钱来优先改进他们的编辑器。 代码完成获得的 GopherCoin 平均数量最高。 一半的受访者对前 4 项功能（代码完成、代码导航、编辑器性能和重构）给出了 10 个或更多硬币。

大多数受访者 (63%) 将 10-30% 的时间用于重构，这表明这是一项常见任务，我们希望研究改进它的方法。 它还解释了为什么重构支持是最受资助的编辑器改进之一。

去年我们询问了特定的开发人员技术，发现几乎 90% 的受访者使用文本日志进行调试，所以今年我们添加了一个后续问题来找出原因。 结果表明，43% 的人使用它是因为它允许他们在不同的语言中使用相同的调试策略，42% 的人更喜欢使用文本日志而不是其他调试技术。 然而，27% 的人不知道如何开始使用 Go 的调试工具，24% 的人从未尝试过使用 Go 的调试工具，因此有机会在可发现性、可用性和文档方面改进调试器工具。 此外，由于四分之一的受访者从未尝试过使用调试工具，因此可能会低估痛点。

对 Go 的满意程度

今年我们第一次询问整体满意度。 92% 的受访者表示他们对过去一年使用 Go 非常满意或有些满意。
这是我们第三年问“你会推荐……”净推荐值 (NPS) 问题。 今年我们的 NPS 结果是 61（68% 的“推荐者”减去 6% 的“批评者”），与 2019 年和 2018 年相比，在统计上没有变化。

与往年类似，91% 的受访者表示他们更愿意在下一个新项目中使用 Go。 89% 的人表示 Go 为他们的团队工作得很好。 今年，我们看到越来越多的受访者认为 Go 对其公司的成功至关重要，从 2019 年的 59% 增加到 2020 年的 66%。在拥有 5,000 名或更多员工的组织中工作的受访者不太可能同意 (63%)，而那些在较小的组织中，更可能同意 (73%)。

与去年一样，我们要求受访者根据满意度和重要性对 Go 开发的特定领域进行评分。 对使用云服务、调试和使用模块（去年被强调为改进机会的领域）的满意度有所提高，而大多数重要性得分保持不变。 我们还介绍了几个新主题：API 和 Web 框架。 我们看到 Web 框架的满意度低于其他领域（64%）。 对于大多数当前用户来说，它并不是那么重要（只有 28% 的受访者表示它非常重要或极其重要），但对于潜在的 Go 开发人员来说，它可能是一个缺失的关键功能。

81% 的受访者表示他们觉得使用 Go 非常或非常高效。 与较小组织的受访者相比，较大组织的受访者更有可能感到非常高效。

我们听说过使用 Go 很容易快速提高生产力。 我们询问了那些感觉至少有一点生产力的受访者，他们花了多长时间才变得有生产力。 93% 的人表示用了不到一年的时间，大多数人在 3 个月内就觉得很有成效。

尽管与去年大致相同，但同意“我在 Go 社区感到受欢迎”这一说法的受访者百分比似乎随着时间的推移呈下降趋势，或者至少没有像其他领域一样保持上升趋势。

我们还看到，认为 Go 的项目领导了解他们需求的受访者比例（63%）同比显着增加。

所有这些结果都表明，从大约两年开始，更高的一致性模式与 Go 经验的增加相关。 换句话说，受访者使用 Go 的时间越长，他们就越有可能同意这些陈述中的每一个。

我们问了一个关于我们可以做些什么来让 Go 社区更受欢迎的开放文本问题，最常见的建议 (21%) 与学习资源和文档的不同形式或改进/添加有关。

使用 Go 工作

构建 API/RPC 服务 (74%) 和 CLI (65%) 仍然是 Go 最常见的用途。 与去年相比，我们没有看到任何重大变化，当时我们在选项的排序中引入了随机化。 （在 2019 年之前，不成比例地选择了列表开头的选项。）我们还按组织规模对此进行了分解，发现受访者在大型企业或小型组织中使用 Go 的情况类似，尽管大型组织使用 Go 的可能性稍低用于返回 HTML 的 Web 服务。

今年，我们现在对受访者在家中和工作中使用 Go 编写的软件类型有了更好的了解。 尽管返回 HTML 的 Web 服务是第四个最常见的用例，但这是由于与工作无关的使用。 与返回 HTML 的 Web 服务相比，更多的受访者将 Go 用于自动化/脚本、代理和守护程序以及工作数据处理。 大部分最不常见的用途（桌面/GUI 应用程序、游戏和移动应用程序）是在工作之外编写的。

另一个新问题询问受访者对每个用例的满意程度。 CLI 的满意度最高，85% 的受访者表示他们对使用 Go for CLI 非常、中等或略微满意。 Go 的常见用途往往具有更高的满意度分数，但满意度和受欢迎程度并不完全对应。 例如，代理和守护进程的满意度排名第二，但使用率排名第六。

其他后续问题探讨了不同的用例，例如，受访者的 CLI 以哪些平台为目标。 考虑到 Linux (93%) 和 macOS (59%) 的高代表率并不奇怪，因为开发人员对 Linux 和 macOS 的使用率很高，而且 Linux 云使用率很高），但即使是 Windows 也是近三分之一的 CLI 开发人员的目标。

对 Go 进行数据处理的仔细研究表明，Kafka 是唯一被广泛采用的引擎，但大多数受访者表示他们将 Go 与自定义数据处理引擎一起使用。

我们还询问了受访者使用 Go 的更大领域。 迄今为止，最常见的领域是 Web 开发（68%），但其他常见领域包括数据库（46%）、DevOps（42%）、网络编程（41%）和系统编程（40%）。

与去年类似，我们发现 76% 的受访者评估当前的 Go 版本用于生产用途，但今年我们改进了我们的时间尺度，发现 60% 的受访者在发布前或发布后的 2 个月内开始评估新版本。 这凸显了平台即服务提供商快速支持 Go 新稳定版本的重要性。

模块

今年我们发现 Go 模块几乎被普遍采用，并且仅使用模块进行包管理的受访者比例显着增加。 96% 的受访者表示他们使用模块进行包管理，高于去年的 89%。 87% 的受访者表示他们只使用模块进行包管理，高于去年的 71%。 同时，其他包管理工具的使用减少了。

对模块的满意度也比去年有所增加。 77% 的受访者表示他们对模块非常、中等或略微满意，而 2019 年这一比例为 68%。

官方文档

大多数受访者表示，他们在处理官方文件时遇到了困难。 62% 的受访者难以找到足够的信息来完全实现其应用程序的功能，超过三分之一的受访者难以开始他们以前从未做过的事情。

官方文档中最有问题的领域是使用模块和 CLI 开发，20% 的受访者认为模块文档没有帮助或根本没有帮助，16% 的受访者认为围绕 CLI 开发的文档。

Go 在云上的使用

Go 的设计考虑了现代分布式计算，我们希望继续改进使用 Go 构建云服务的开发人员体验。

• 全球三大云提供商（亚马逊网络服务、谷歌云平台和微软 Azure）在调查受访者中的使用量继续增加，而大多数其他提供商每年使用的受访者比例较小。 特别是 Azure，从 7% 显着增加到 12%
• 作为最常见的部署目标，到自有或公司拥有的服务器的本地部署继续减少

部署到 AWS 和 Azure 的受访者发现部署到托管 Kubernetes 平台的比例有所增加，现在分别增加了 40% 和 54%。 Azure 发现将 Go 程序部署到 VM 的用户比例显着下降，容器使用率从 18% 增长到 25%。 与此同时，GCP（已经有很高比例的受访者报告了托管 Kubernetes 的使用）部署到无服务器 Cloud Run 的比例从 10% 增加到 17%。

总体而言，大多数受访者对在所有三大云供应商上使用 Go 感到满意，而且这些数字与去年相比在统计上没有变化。 受访者对 AWS（82% 满意）和 GCP（80%）的 Go 开发表示了相似的满意度。 Azure 的满意度得分较低（58% 满意），并且自由文本回复经常提到需要改进 Azure 的 Go SDK 和 Go 对 Azure 功能的支持。

痛点

受访者表示他们无法更多地使用 Go 的主要原因仍然是在用另一种语言的项目上工作 (54%)，在一个更喜欢使用另一种语言的团队中工作 (34%)，以及 Go 本身缺乏关键功能 (26%)。

今年我们引入了一个新选项，“我已经在任何我想要的地方使用 Go”，这样受访者就可以选择不进行不妨碍他们使用 Go 的选择。 这显着降低了所有其他选项的选择率，但并没有改变它们的相对顺序。 我们还为“Go 缺乏关键框架”引入了一个选项。

如果我们只查看选择不使用 Go 的原因的受访者，我们可以更好地了解同比趋势。 随着时间的推移，使用另一种语言处理现有项目以及项目/团队/领导对另一种语言的偏好正在减少。

在 26% 的受访者表示 Go 缺乏他们需要的语言功能，88% 的受访者选择泛型作为关键的缺失功能。 其他重要的缺失特性包括更好的错误处理 (58%)、空安全 (44%)、函数式编程特性 (42%) 和更强大/扩展的类型系统 (41%)。

需要明确的是，这些数字来自一部分受访者，他们表示如果没有遗漏他们需要的一个或多个关键功能，他们将能够更多地使用 Go，而不是整个调查受访者群体。 从这个角度来看，由于缺乏泛型，18% 的受访者被阻止使用 Go。

受访者在使用 Go 时报告的最大挑战再次是 Go 缺乏泛型（18%），而模块/包管理和学习曲线/最佳实践/文档的问题均为 13%。

Go 社区

今年，我们询问了受访者回答围棋相关问题的 5 大资源。 去年我们只要求前 3 名，所以结果没有直接可比性，但是 StackOverflow 仍然是最受欢迎的资源，占 65%。 阅读源代码 (57%) 仍然是另一个受欢迎的资源，而对 godoc.org (39%) 的依赖已显着减少。 软件包发现网站 pkg.go.dev 是今年新上榜的，并且是 32% 受访者的首选资源。 使用 pkg.go.dev 的受访者更有可能同意他们能够快速找到他们需要的 Go 包/库：pkg.go.dev 用户为 91%，其他人为 82%。

多年来，不参加 Go 相关活动的受访者比例一直呈上升趋势。 由于 Covid-19，今年我们修改了关于Go 事件的问题，发现超过四分之一的受访者在网上 Go 频道上花费的时间比往年多，14% 的人参加了虚拟 Go 聚会，是去年的两倍。 64% 参加虚拟活动的人表示这是他们的第一次虚拟活动。

我们发现 12% 的受访者认同传统上代表性不足的群体（例如种族、性别认同等），与 2019 年相同，2% 的受访者认同女性，低于 2019 年（3%）。 与不认同弱势群体的受访者相比，认同弱势群体的受访者对“我在 Go 社区感到受欢迎”这一陈述的异议率更高（10% 对 4%）。 这些问题使我们能够衡量社区的多样性，并突出宣传和发展的机会。


今年我们增加了一个关于辅助技术使用的问题，发现 8% 的受访者正在使用某种形式的辅助技术。 最常用的辅助技术是对比度或颜色设置 (2%)。 这是一个很好的提醒，我们有用户有可访问性需求，并有助于推动我们在 Go 团队管理的网站上做出一些设计决策。

Go 团队重视多样性和包容性，这不仅是正确的做法，而且因为多样化的声音可以照亮我们的盲点并最终使所有用户受益。 我们询问敏感信息的方式，包括性别和传统上代表性不足的群体，已根据数据隐私法规发生变化，我们希望在未来使这些问题，特别是关于性别多样性的问题更具包容性。

总结

感谢您与我们一起查看 2020 年开发者调查的结果！ 了解开发人员的经验和挑战有助于我们衡量我们的进展并指导 Go 的未来。 再次感谢所有为本次调查做出贡献的人——没有你们，我们不可能完成这项工作。 我们希望明年再见！