背景

Go 的设计注重开发者体验，我们非常重视通过提案、问题反馈和社区互动收到的反馈。然而，这些渠道通常代表了我们最有经验或参与度最高用户的声音，他们只是更广泛的 Go 社区的一小部分。为了确保我们能够服务于所有技能水平的开发者，包括那些可能对语言设计没有强烈意见的开发者，我们每年会进行一到两次此调查，以收集系统性的反馈和定量证据。这种包容性的方法使我们能够听到来自更广泛的 Go 开发者的声音，从而为 Go 在不同背景和经验水平下的使用方式提供宝贵的见解。您的参与对于我们关于语言变更和资源分配的决策至关重要，并最终塑造 Go 的未来。感谢所有做出贡献的人，我们强烈鼓励您继续参与未来的调查。您的体验对我们很重要。

本文分享了我们最近一次 Go 开发者调查的结果，该调查于 2024 年 9 月 9 日至 23 日进行。我们通过 Go 博客以及 VS Code Go 插件和 GoLand IDE 中的随机提示招募了参与者，从而能够招募到更有代表性的 Go 开发者样本。我们共收到了 4,156 份回复。非常感谢所有为实现这一目标做出贡献的人。

除了收集使用 Go 和 Go 工具的感受和挑战外，本次调查的主要关注领域是揭示重复性劳动（toil）的来源、执行最佳实践的挑战以及开发者如何使用 AI 辅助。

亮点

• 开发者对 Go 的情绪仍然非常积极，93% 的调查受访者表示在过去一年中对使用 Go 感到满意。
• 在三大云服务提供商上使用 Go 时，**易于部署和易于使用的 API/SDK** 是受访者最喜欢的地方。一流的 Go 支持对于满足开发者的期望至关重要。
• 70% 的受访者在使用 Go 进行开发时正在使用 AI 助手。最常见的用途是 **LLM 驱动的代码补全**、编写测试、根据自然语言描述生成 Go 代码以及头脑风暴。受访者去年表示希望使用 AI 的场景，与他们目前实际使用的场景之间存在显著差异。
• 使用 Go 的团队面临的最大挑战是**跨代码库维护一致的编码标准**。这通常是由于团队成员的 Go 经验水平不同，并且来自不同的编程背景，导致编码风格不一致以及采用非惯用模式。

目录

• 总体满意度
• 开发环境和工具
• Go 在云端
• AI 辅助
• Go 团队面临的挑战
• 单指令多数据 (SIMD)
• 人口统计
• 企业信息
• 方法论
• 如何解读这些结果
• 结语

总体满意度

总体满意度在调查中仍然很高，93% 的受访者表示在过去一年中对 Go 感到某种程度或非常满意。尽管百分比会随着周期略有波动，但与我们 2023 年 H2（满意率为 90%）或 2024 年 H1（满意率为 93%）的调查相比，我们没有发现任何统计学上的显著差异。

我们在调查中收到的公开评论继续突显了开发者最喜欢 Go 的地方，例如它的简洁性、Go 工具链以及其向后兼容的承诺。

“我是一个编程语言爱好者（类 C 语言），我总是回到 Go，因为它简洁、编译速度快且工具链强大。请保持下去！”

“感谢创造了 Go！这是我最喜欢的语言，因为它非常简洁，开发周期拥有快速的构建-测试循环，并且在使用随机的 Go 开源项目时，即使在 10 年后，它也很可能正常工作。我喜欢 1.0 的兼容性保证。”

开发环境和工具

开发者操作系统

与往年一致，大多数调查受访者在 Linux（61%）和 macOS（59%）系统上使用 Go 进行开发。历史上，Linux 和 macOS 用户的比例非常接近，我们没有看到与上次调查有任何显著变化。来自 JetBrains 和 VS Code 的随机抽样组在 Windows 上开发的比例（分别为 33% 和 36%）高于自选组（16%）。

部署环境

鉴于 Go 在云开发和容器化工作负载中的普及，Go 开发者主要部署到 Linux 环境（96%）也就不足为奇了。

我们包含了一些问题，以了解受访者在部署到 Linux、Windows 或 WebAssembly 时所使用的架构。x86-64 / AMD64 架构是部署到 Linux（92%）和 Windows（97%）的最受欢迎的选择。ARM64 紧随其后，在 Linux 上占 49%，在 Windows 上占 21%。

部署到 WebAssembly 的受访者不多（仅占总体受访者的约 4%），但在部署到 WebAssembly 的人中，73% 表示部署到 JS，48% 表示部署到 WASI Preview 1。

编辑器认知度和偏好

我们在本次调查中增加了一个新问题，以评估对 Go 的流行编辑器的认知度和使用情况。在解读这些结果时，请记住，34% 的受访者是通过 VS Code 进入调查的，9% 的受访者来自 GoLand，因此他们更可能定期使用这些编辑器。

VS Code 是使用最广泛的编辑器，66% 的受访者定期使用，GoLand 是第二常用的，占 35%。几乎所有受访者都听说过 VS Code 和 GoLand，但受访者更有可能至少尝试过 VS Code。有趣的是，33% 的受访者表示他们定期使用 2 个或更多编辑器。他们可能为不同的任务或环境使用不同的编辑器，例如通过 SSH 使用 Emacs 或 Vim，而 IDE 不可用。

我们还问了一个关于编辑器偏好的问题，这与我们之前调查中问过的一样。由于我们的随机抽样人群是从 VS Code 或 GoLand 中招募的，因此他们对这些编辑器的偏好有很强的倾向性。为避免结果失衡，我们仅显示自选组的偏好编辑器数据。38% 的人偏好 VS Code，35% 的人偏好 GoLand。这与上次 H1 调查相比有了显著差异，当时 43% 的人偏好 VS Code，33% 的人偏好 GoLand。一种可能的解释是今年的招募方式。今年，VS Code 通知在 Go 博客文章发布之前就开始邀请开发者参加调查，因此今年来自 VS Code 提示的受访者比例更大，他们原本可能来自博客文章。由于我们在此图表中仅显示自选受访者，因此来自 VS Code 提示的数据未在此处显示。另一个因素可能是偏好“其他”（4%）的人数略有增加。填写评论的回复表明，对 Zed 等编辑器兴趣增加，其占填写评论回复的 43%。

代码分析工具

最流行的代码分析工具是 gopls，65% 的受访者知情使用。由于 gopls 在 VS Code 中默认在后台使用，这很可能是一个低估。紧随其后的是 golangci-lint，57% 的受访者使用；staticcheck，34% 的受访者使用。使用自定义或则其他工具的比例要小得多，这表明大多数受访者更喜欢常见且成熟的工具，而不是自定义解决方案。只有 10% 的受访者表示他们不使用任何代码分析工具。

Go 在云端

Go 是现代云开发的热门语言，因此我们通常会在调查中包含问题，以帮助我们了解 Go 开发者正在使用哪些云平台和服务。在本周期，我们旨在了解 Go 开发者在云提供商之间的偏好和体验，并特别关注最大的云提供商：Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud。我们还为那些部署到没有虚拟化的服务器的开发者增加了“裸机服务器”选项。

与往年类似，近一半的受访者（50%）将 Go 程序部署到 Amazon Web Services。AWS 之后是自营或公司拥有的服务器（37%）和 Google Cloud（30%）。在大公司工作过的受访者比在中小型公司工作过的受访者（34%）更有可能部署到自营或公司拥有的服务器（48%）。他们也比中小型组织（12%）更有可能部署到 Microsoft Azure（25%）。

最常用的云服务是 AWS Elastic Kubernetes Service (41%)、AWS EC2 (39%) 和 Google Cloud GKE (29%)。尽管我们看到 Kubernetes 的使用率随时间增长，但这是 EKS 的使用率首次超过 EC2。总体而言，Kubernetes 服务是 AWS、Google Cloud 和 Azure 最受欢迎的服务，其次是虚拟机，然后是无服务器产品。Go 在容器化和微服务开发方面的优势与 Kubernetes 的日益普及自然契合，因为它为部署和管理这些类型的应用程序提供了高效且可扩展的平台。

我们向将 Go 代码部署到三大云提供商（Amazon Web Services、Google Cloud 和 Microsoft Azure）的受访者提出了一个后续问题，询问他们最喜欢将 Go 代码部署到每个云的哪些方面。跨不同提供商最受欢迎的回答实际上是 Go 的性能和语言特性，而不是关于云提供商的任何内容。

其他常见原因包括

• 与使用其他云相比，熟悉给定的云提供商
• 在给定的云提供商上轻松部署 Go 应用程序
• 云提供商为 Go 提供的 API/SDK 易于使用
• API/SDK 文档齐全

除了熟悉度之外，最受欢迎的特点突显了拥有对 Go 的一流支持以满足开发者期望的重要性。

受访者中，相当一部分人表示他们对云提供商没有最喜欢的地方。从早期版本的调查（涉及填写评论的回复）来看，这通常意味着他们不直接与云交互。特别是，使用 Microsoft Azure 的受访者比使用 AWS（27%）或 Google Cloud（30%）的受访者更有可能表示“没有任何优点”是他们最喜欢的地方（51%）。

AI 辅助

Go 团队推测，AI 辅助有潜力将开发者从繁琐重复的任务中解放出来，让他们能够专注于工作中更具创造性和令人满足的方面。为了深入了解 AI 辅助可能最有益的领域，我们在调查中包含了一个部分，以识别常见的开发者重复性劳动。

大多数受访者（70%）在 Go 开发中使用 AI 助手。AI 助手的最常见用途是 LLM 驱动的代码补全（35%）。其他常见回应是编写测试（29%）、根据自然语言描述生成 Go 代码（27%）以及头脑风暴想法（25%）。还有相当一部分受访者（30%）在上个月没有使用过任何 LLM 进行辅助。

与我们 2023 年 H2 调查的结果相比，其中一些结果尤为突出。在那次调查中，我们询问了受访者希望 AI/ML 支持 Go 开发者的前 5 个用例。尽管本期调查引入了一些新回应，但我们仍然可以粗略比较受访者表示希望获得 AI 支持的场景与其实际使用情况。在之前的调查中，编写测试是最受欢迎的用例（49%）。在我们最新的 2024 年 H2 调查中，约 29% 的受访者在上个月曾使用 AI 助手进行此操作。这表明当前的解决方案未能满足开发者在编写测试方面的需求。同样，在 2023 年，47% 的受访者表示希望在编码时获得最佳实践建议，而在一年后的 2024 年，只有 14% 的受访者表示他们使用 AI 助手来处理这个用例。46% 的人表示希望获得帮助以发现编码中的常见错误，而只有 13% 的人表示他们为此使用了 AI 助手。这可能表明当前的 AI 助手并不擅长处理这些任务，或者它们与开发者的工作流程或工具集成不佳。

看到 AI 在根据自然语言生成 Go 代码和进行头脑风暴方面的使用率如此之高也令人惊讶，因为之前的调查并未将这些视为高度期望的用例。这些差异可能有多种解释。虽然之前的受访者最初可能并未明确希望 AI 用于代码生成或头脑风暴，但他们可能正在转向这些用途，因为它们符合生成式 AI 的当前优势——自然语言处理和创意文本生成。我们也应该记住，人们不一定是他们自身行为的最佳预测者。

我们还发现不同群体在回答此问题时存在一些显著差异。中小型组织的受访者使用 LLM 的可能性（75%）略高于大型组织（66%）。这可能有多种原因，例如，大型组织可能有更严格的安全和合规性要求，以及对 LLM 编码助手安全性、数据泄露的可能性或遵守行业特定法规的担忧。他们也可能已经投资于其他开发工具和实践，这些工具和实践已经为开发者生产力提供了类似的好处。

拥有不到 2 年 Go 经验的 Go 开发者比拥有 5 年以上经验的 Go 开发者更有可能使用 AI 助手（75% vs 67%）。经验较少的 Go 开发者也更有可能将 AI 用于更多任务，平均为 3.50 项。尽管所有经验水平都倾向于使用 LLM 驱动的代码补全，但经验较少的 Go 开发者更有可能使用 Go 来完成与学习和调试相关的更多任务，例如解释某段 Go 代码的功能、解决编译器错误以及调试 Go 代码中的失败。这表明 AI 助手目前为那些对 Go 不太熟悉的人提供了最大的实用性。我们不知道 AI 助手如何影响学习或在新 Go 项目的启动，这是我们未来希望进行调查的内容。但是，所有经验水平的开发者对 AI 助手的满意度都差不多，约为 73%，因此新 Go 开发者的满意度并没有更高，尽管他们使用得更频繁。

对于报告至少在一项与 Go 代码编写相关的任务中使用 AI 辅助的受访者，我们提出了一些后续问题，以进一步了解他们的 AI 助手使用情况。最常用的 AI 助手是 ChatGPT（68%）和 GitHub Copilot（50%）。当被问及上个月“最”常使用的 AI 助手时，ChatGPT 和 Copilot 的比例差不多，均为 36%，因此尽管使用 ChatGPT 的受访者更多，但这不一定就是他们的主要助手。参与者对这两个工具的满意度相似（ChatGPT 满意度为 73%，GitHub CoPilot 为 78%）。任何 AI 助手的最高满意率是 Anthropic Claude，为 87%。

Go 团队面临的挑战

在本调查部分，我们希望了解哪些最佳实践或工具应该更好地集成到开发者的工作流程中。我们的方法是识别 Go 团队面临的常见问题。然后，我们询问受访者，如果某些挑战能够被“神奇地”解决，他们将获得最大的好处。（这样做的目的是让受访者不关注具体的解决方案。）能够带来最大好处的常见问题将被视为改进的候选。

团队最常报告的挑战是跨 Go 代码库维护一致的编码标准（58%），识别正在运行的 Go 程序的性能问题（58%），以及识别正在运行的 Go 程序的资源使用效率低下（57%）。

21% 的受访者表示，他们的团队将在跨 Go 代码库维护一致的编码标准方面受益最大。这是最常见的回复，使其成为一个很好的解决目标。在后续问题中，我们获得了更多关于为什么这如此具有挑战性的细节。

根据填写评论的回复，许多团队在维护一致的编码标准方面面临挑战，因为他们的成员具有不同水平的 Go 经验，并且来自不同的编程背景。这导致编码风格不一致和采用非惯用模式。

“在我工作的公司，有很多掌握多种语言的工程师。所以写出来的 Go 代码不一致。我自认为是一个 Gopher，并花时间试图说服我的队友什么是 Go 语言中的惯用写法”—拥有 2-4 年经验的 Go 开发者。

“团队成员大多从零开始学习 Go。从动态类型语言转过来，他们需要一段时间才能适应新语言。他们似乎在按照 Go 指南维护代码一致性方面遇到困难”—拥有 2-4 年经验的 Go 开发者。

这呼应了我们之前听到的一些关于同事写“Gava”或“Guby”的反馈，因为他们之前的语言经验。尽管静态分析是我们在此问题上考虑解决此类问题时想到的工具类别，但我们目前正在探索可能解决此问题的方法。

单指令多数据 (SIMD)

SIMD，即单指令多数据，是一种并行处理类型，它允许单个 CPU 指令同时处理多个数据点。这有助于处理涉及大型数据集和重复操作的任务，并通常用于优化游戏开发、数据处理和科学计算等领域的性能。在本调查部分，我们希望评估受访者对 Go 中原生 SIMD 支持的需求。

大多数受访者（89%）表示，他们至少有时会在性能优化至关重要的项目中工作。40% 的人表示他们至少一半的时间都在这类项目上工作。这在不同规模的组织和经验水平中都普遍存在，表明性能对大多数开发者来说是一个重要问题。

大约一半的受访者（54%）表示，他们至少对 SIMD 的概念有些了解。使用 SIMD 通常需要对计算机体系结构和底层编程概念有更深入的理解，因此不足为奇的是，我们发现经验较少的开发者对 SIMD 的了解程度较低。更有经验并且至少一半时间从事性能关键型应用程序的受访者最有可能熟悉 SIMD。

对于那些至少对 SIMD 有些了解的人，我们提出了一些后续问题，以了解受访者受到 Go 中缺乏原生 SIMD 支持的影响。超过三分之一，约 37% 的人表示他们受到了影响。17% 的受访者表示他们的项目性能受到了限制，15% 的受访者表示他们不得不使用另一种语言而不是 Go 来实现目标，13% 的受访者表示他们不得不使用非 Go 库，尽管他们本希望使用 Go 库。有趣的是，受 SIMD 原生支持缺失负面影响的受访者更倾向于将 Go 用于数据处理和 AI/ML。这表明添加 SIMD 支持可以使 Go 成为这些领域的更好选择。

人口统计

我们在每个调查周期都会提出类似的人口统计学问题，以便我们了解与往年相比结果的可比性。例如，如果我们看到回应者在 Go 经验方面发生了变化，那么其他结果与之前周期的差异很可能归因于这种人口结构的变化。我们还使用这些问题来提供组之间的比较，例如根据受访者使用 Go 的时间长短来比较满意度。

在本周期，我们没有看到受访者经验水平有任何显著变化。

根据受访者是来自 Go 博客、VS Code 扩展还是 GoLand，他们的个人统计数据存在差异。在 VS Code 中对调查通知作出回应的人群更倾向于 Go 经验较少；我们怀疑这是 VS Code 受新 Go 开发者欢迎程度的反映，他们在学习过程中可能还没有准备好投资 IDE 许可证。就 Go 经验年限而言，从 GoLand 随机抽样的受访者与我们通过 Go 博客找到调查的自选人群更为相似。看到样本之间的一致性使我们能够更自信地将调查结果推广到整个社区。

除了 Go 经验年限外，我们还衡量了专业编码经验年限。我们的受众往往是一群非常有经验的人，26% 的受访者拥有 16 年以上的专业编码经验。

自选组比随机抽样组经验更丰富，29% 的人拥有 16 年以上的专业经验。这表明我们的自选组通常比随机抽样组更有经验，这可以解释我们在此组中看到的一些差异。

我们发现 81% 的受访者全职就业。当我们查看个人样本时，我们看到来自 VS Code 的受访者之间存在微小但显著的差异，他们更可能是学生。考虑到 VS Code 是免费的，这很合理。

与往年类似，Go 最常见的用例是 API/RPC 服务（75%）和命令行工具（62%）。更有经验的 Go 开发者报告使用 Go 构建了更多种类的应用程序。这一趋势在所有类型的应用程序或服务中都保持一致。我们没有发现受访者根据其组织规模在构建内容方面存在任何显著差异。来自随机 VS Code 和 GoLand 样本的受访者也没有显示出显著差异。

企业信息

我们听取了来自各种不同组织的受访者的意见。约 29% 的人来自大型组织（1,001 名或更多员工），25% 来自中型组织（101-1,000 名员工），43% 来自小型组织（少于 100 名员工）。与往年一样，人们从事最多的行业是技术（43%），其次是金融服务（13%）。

与之前的调查一样，调查受访者最常见的地点是美国（19%）。今年，我们看到了来自乌克兰的受访者比例显著增加，从 1% 增加到 6%，使其成为受访者第三多的地点。由于我们仅在自选受访者中看到此差异，而在随机抽样组中未观察到，这表明是某些因素影响了谁发现了调查，而不是乌克兰所有开发者对 Go 的采用普遍增加。也许在乌克兰的开发者中，对调查或 Go 博客的可见性或认知度有所提高。

方法论

我们主要通过 Go 博客发布调查公告，该公告通常会在 Reddit 或 Hacker News 等各种社交渠道上被转载。我们还通过使用 VS Code Go 插件随机选择用户，并向他们显示一个询问他们是否愿意参与调查的提示来招募受访者。在 JetBrains 的朋友们的帮助下，我们还从提示 GoLand 用户子集参加调查中获得了额外的随机样本。这为我们提供了两个来源，用于将来自传统渠道的自选受访者进行比较，并帮助识别自选偏倚的潜在影响。

57% 的调查受访者“自愿”参加了调查，这意味着他们是通过 Go 博客或其他 Go 社交渠道发现的。不关注这些渠道的人不太可能从这些渠道了解到调查，在某些情况下，他们的回应方式与密切关注这些渠道的人不同。例如，他们可能是 Go 社区的新成员，还没有意识到 Go 博客。约 43% 的受访者是随机抽样的，这意味着他们在看到 VS Code（25%）或 GoLand（11%）中的提示后响应了调查。在 2024 年 9 月 9 日至 23 日期间，VS Code 插件用户看到此提示的概率约为 10%。GoLand 中的提示在 9 月 9 日至 20 日之间也类似地活跃。通过检查随机抽样组与自选回应的差异，以及彼此之间的差异，我们可以更有信心地将调查结果推广到更广泛的 Go 开发者社区。

如何解读这些结果

在整个报告中，我们使用调查回应图表来为我们的发现提供支持性证据。所有这些图表都使用类似的格式。标题是调查受访者看到的原始问题。除非另有说明，否则问题是多项选择题，参与者只能选择一个选项；每个图表的副标题会告知读者该问题是否允许选择多个选项，或者是否是开放式文本框而不是多项选择题。对于开放式文本回应的图表，Go 团队成员会阅读并手动分类所有回应。许多开放式问题会引起各种各样的回应；为了使图表大小合理，我们将它们精简为最多前 10-12 个主题，并将其他主题全部归入“其他”。图表中显示的百分比标签四舍五入到最接近的整数（例如，1.4% 和 0.8% 都将显示为 1%），但每个条的长度和行顺序都基于未四舍五入的值。

为了帮助读者理解每个发现背后的证据权重，我们包含了显示 95% 置信区间的误差条；更窄的条形表示更高的置信度。有时两个或多个回应的误差条重叠，这意味着这些回应的相对顺序在统计学上没有意义（即，这些回应实际上是并列的）。每个图表的右下角显示了包含在图表中的受访者人数，格式为“n = [受访者人数]”。在发现组之间存在有趣差异的情况下（例如，经验年限、组织规模或样本来源），我们显示了差异的颜色编码细分。

结语

感谢您审阅我们的半年度 Go 开发者调查！并非常感谢所有分享他们对 Go 看法的人以及所有为使此次调查成为可能而做出贡献的人。这对我们意义重大，并真正帮助我们改进 Go。

— Alice（代表 Google Go 团队）