Go 博客

Go 开发者调查 2020 年结果

Alice Merrick
2021年3月9日

感谢您的热烈响应！

2020 年，我们再次获得了热烈响应，共有 9,648 份回复，数量与 2019 年大致相同。感谢您抽出宝贵时间，向社区提供了关于您使用 Go 经验的这些见解！

新的模块化调查设计

您可能会注意到某些问题的样本量（“n=”）小于其他问题。这是因为有些问题对所有受访者显示，而另一些问题仅对随机抽取的受访者子集显示。

要点

• Go 在工作场所和企业中的使用正在扩大，76% 的受访者在工作中使用 Go，66% 的受访者表示 Go 对他们公司的成功至关重要。
• 总体满意度很高，92% 的受访者对使用 Go 表示满意。
• 大多数 受访者在不到 3 个月内就觉得使用 Go 很有生产力，其中 81% 的受访者感觉使用 Go 非常或极其有生产力。
• 受访者表示及时升级到最新的 Go 版本，其中 76% 在前 5 个月内完成升级。
• 使用 pkg.go.dev 的受访者在查找 Go 包方面更成功（91%），而非用户成功率为 82%。
• Go 模块的采用几乎是普遍的，满意度达 77%，但受访者也强调需要改进文档。
• Go 继续被大量用于 API、CLI、Web、DevOps 和数据处理。
• 代表性不足的群体在社区中往往感到不太受欢迎。

我们听取了哪些人的意见？

人口统计问题有助于我们区分哪些同比差异可能来自受访者构成变化，哪些来自情绪或行为变化。由于我们的人口统计信息与去年相似，我们可以合理地确信其他同比变化并非主要由于人口结构变化造成。

例如，从 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”（一种虚构货币），并根据他们愿意花费的金额来优先排序编辑器改进。代码补全收到的 GopherCoins 平均数量最高。一半的受访者为前 4 项功能（代码补全、代码导航、编辑器性能和重构）分配了 10 个或更多的 GopherCoins。

大多数受访者（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 开发 CLI 非常、中度或稍微满意。Go 的常见用途通常具有较高的满意度得分，但满意度和流行度并不完全对应。例如，代理和守护进程的满意度比例位居第二，但其使用率仅排在第六。

进一步的后续问题探讨了不同的用例，例如受访者的 CLI 目标平台。考虑到开发者对 Linux 和 macOS 的高使用率以及 Linux 云平台的高使用率，看到 Linux (93%) 和 macOS (59%) 的高代表性并不令人惊讶，但即使是 Windows 也被近三分之一的 CLI 开发者作为目标平台。

对 Go 进行数据处理的深入分析显示，Kafka 是唯一广泛采用的引擎，但大多数受访者表示他们使用 Go 和自定义数据处理引擎。

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

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

模块

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

对模块的满意度也较去年有所提高。77% 的受访者表示他们对模块非常、中度或稍微满意，而 2019 年为 68%。

官方文档

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

官方文档中最有问题的领域是关于使用模块和 CLI 开发，20% 的受访者认为模块文档稍微或完全没有帮助，16% 的受访者认为 CLI 开发相关文档稍微或完全没有帮助。

Go 与云

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

• 全球三大云服务提供商（亚马逊云服务 AWS、谷歌云平台 GCP 和微软 Azure）在受访者中的使用量持续增长，而大多数其他提供商每年都被较小比例的受访者使用。尤其是 Azure，使用量从 7% 显著增加到 12%。
• 将应用程序部署到自有机房或公司自有服务器的本地部署（On-prem）作为最常见的部署目标的比例持续下降。

部署到 AWS 和 Azure 的受访者中，部署到托管 Kubernetes 平台的比例有所增加，现在分别为 40% 和 54%。Azure 的用户中，部署 Go 程序到虚拟机的比例显著下降，容器使用量从 18% 增长到 25%。与此同时，GCP（已有较高比例的受访者报告使用托管 Kubernetes）在部署到无服务器 Cloud Run 方面也有所增长，从 10% 增长到 17%。

总体而言，大多数受访者对在所有三大主要云服务提供商上使用 Go 表示满意，且数据与去年统计上没有变化。受访者对在 AWS（82% 满意）和 GCP（80%）上进行 Go 开发的满意度水平相似。Azure 的满意度得分较低（58% 满意），自由文本回复中经常提到需要改进 Azure 的 Go SDK 以及对 Azure Functions 的 Go 支持。

痛点

受访者表示他们无法更多使用 Go 的主要原因仍然是：正在用其他语言开发项目（54%），团队更倾向于使用其他语言（34%），以及 Go 本身缺乏关键功能（26%）。

今年我们引入了一个新选项：“我已经在所有想用的地方都使用了 Go”，以便受访者可以选择退出那些并非阻止他们使用 Go 的选项。这显著降低了所有其他选项的选择率，但并未改变它们的相对顺序。我们还引入了一个选项：“Go 缺乏关键框架”。

如果我们只看那些选择原因说明为何没有更多使用 Go 的受访者，我们可以更好地了解同比趋势。正在用其他语言开发现有项目以及项目/团队/领导偏好其他语言这两个原因的比例随着时间推移正在下降。

在表示 Go 缺乏所需语言功能的 26% 受访者中，88% 选择泛型（generics）作为关键缺失功能。其他关键缺失功能包括更好的错误处理（58%）、空安全（null safety）（44%）、函数式编程特性（42%）以及更强大/更全面的类型系统（41%）。

需要明确的是，这些数字来自表示如果 Go 不缺少他们所需的一个或多个关键功能他们就能更多使用 Go 的那部分受访者，而不是所有参与调查的受访者。从这个角度看，有 18% 的受访者因为缺乏泛型而无法更多地使用 Go。

受访者在使用 Go 时报告的首要挑战再次是 Go 缺乏泛型（18%），而模块/包管理以及学习曲线/最佳实践/文档方面的问题各占 13%。

Go 社区

今年我们询问了受访者解答 Go 相关问题的五大资源。去年我们只询问了三大资源，因此结果不能直接比较，但 Stack Overflow 仍然是最受欢迎的资源，占 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 线下活动（virtual Go meetup），是去年的两倍。参加在线活动的受访者中，64% 表示这是他们首次参加在线活动。

我们发现 12% 的受访者属于传统上的代表性不足群体（例如种族、性别认同等），与 2019 年持平，2% 的受访者为女性，低于 2019 年（3%）。认同为代表性不足群体的受访者对“我在 Go 社区中感到受欢迎”这一说法的不同意率（10% vs. 4%）高于不认同为代表性不足群体的受访者。这些问题使我们能够衡量社区的多样性，并突出外展和增长的机会。

今年我们增加了一个关于辅助技术使用情况的问题，发现 8% 的受访者正在使用某种形式的辅助技术。最常用的辅助技术是对比度或颜色设置（2%）。这极好地提醒我们有存在无障碍需求的 Go 用户，并有助于推动 Go 团队管理的网站的一些设计决策。

Go 团队重视多样性和包容性，这不仅仅是正确的事情，更是因为不同的声音能够照亮我们的盲点，最终造福所有用户。我们询问敏感信息（包括性别和传统代表性不足群体）的方式已根据数据隐私法规进行了调整，我们希望未来能使这些问题，尤其是在性别多样性方面，更具包容性。

结论

感谢您与我们一起回顾了 2020 年开发者调查的结果！了解开发者的经验和挑战有助于我们衡量进度并指导 Go 的未来。再次感谢所有为本次调查做出贡献的人——没有你们，这一切不可能实现。我们期待明年再见！