Go 博客
Go 开发者调查 2024 下半年结果
背景
Go 在设计时着重于开发者体验，我们非常重视通过提案、问题和社区互动收到的反馈。然而，这些渠道通常代表着我们最有经验或最活跃的用户的声音，而这仅占更广泛 Go 社区的一小部分。为了确保我们能服务于所有技能水平的开发者，包括那些可能对语言设计没有强烈意见的开发者，我们每年会进行一到两次这样的调查，以收集系统的反馈和定量证据。这种包容性的方法使我们能够听到更广泛的 Go 开发者群体的声音，为我们了解 Go 在不同情境和经验水平下的使用情况提供了宝贵的见解。您的参与对于我们关于语言更改和资源分配的决策至关重要，最终将塑造 Go 的未来。感谢所有做出贡献的人，我们强烈鼓励您继续参与未来的调查。您的经验对我们很重要。
这篇文章分享了我们最近一次 Go 开发者调查的结果，该调查于 2024 年 9 月 9 日至 23 日进行。我们通过 Go 博客以及在 VS Code Go 插件和 GoLand IDE 中的随机提示招募了参与者，这使我们能够招募到更具代表性的 Go 开发者样本。我们共收到了 4,156 份回复。非常感谢所有为促成这次调查而做出贡献的人。
除了捕捉在使用 Go 和 Go 工具时的感受和挑战之外，本次调查的主要重点是揭示重复性工作、实践最佳实践的挑战以及开发者如何使用 AI 助手。
要点
- 开发者对 Go 的情绪仍然非常积极，93% 的受访者表示他们在过去一年中使用 Go 时感到满意。
- 在排名前三的云提供商上使用 Go 时，受访者最喜欢的是易于部署和易于使用的 API/SDK。一流的 Go 支持对于满足开发者的期望至关重要。
- 70% 的受访者在使用 Go 进行开发时使用了 AI 助手。最常见的用途是 基于 LLM 的代码补全、编写测试、从自然语言描述生成 Go 代码以及头脑风暴。受访者去年表示他们想用 AI 做什么，与他们目前实际使用 AI 做什么之间存在显著差异。
- Go 团队面临的最大挑战是在整个代码库中保持一致的编码标准。这通常是因为团队成员具有不同级别的 Go 经验并来自不同的编程背景，导致编码风格不一致以及采用非地道的模式。
目录
总体满意度
总体满意度在本次调查中保持较高水平，93% 的受访者表示他们在过去一年中对 Go 感到有些满意或非常满意。尽管具体百分比在不同周期之间略有波动，但与我们在满意度分别为 90% 和 93% 的 2023 年下半年 和 2024 年上半年 的调查相比，我们没有看到任何统计学上的显著差异。
我们在调查中收到的开放性评论继续强调了开发者最喜欢使用 Go 的地方，例如它的简洁性、Go 工具链以及其承诺的向后兼容性
“我是一个编程语言爱好者（类 C 语言），我总是因为 Go 的简洁性、快速编译和强大的工具链而回到 Go。保持下去！”
“感谢您创建 Go！它是我最喜欢的语言，因为它非常简洁，开发周期构建和测试快速，而且使用一个用 Go 编写的随机开源项目，即使是 10 年后，它也很可能仍然能工作。我喜欢 1.0 的兼容性保证。”
开发环境和工具
开发者操作系统
与往年一致，大多数受访者在 Linux (61%) 和 macOS (59%) 系统上使用 Go 进行开发。历史上，Linux 和 macOS 用户的比例非常接近，我们与上次调查相比没有看到任何显著变化。来自 JetBrains 和 VS Code 的随机抽样群体比自选群体更有可能 (分别为 33% 和 36%) 在 Windows 上进行开发 (16%)。
部署环境
鉴于 Go 在云开发和容器化工作负载中的普及，Go 开发者主要部署到 Linux 环境 (96%) 也就不足为奇了。
我们纳入了几个问题，以了解受访者在部署到 Linux、Windows 或 WebAssembly 时部署到哪种架构。对于部署到 Linux (92%) 和 Windows (97%) 的受访者来说，x86-64 / AMD64 架构是迄今为止最受欢迎的选择。ARM64 在 Linux 中排名第二 (49%)，在 Windows 中排名第二 (21%)。
部署到 Web Assembly 的受访者不多（占总受访者的约 4%），但在其中，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。这与上半年上次调查中的显著差异，当时 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 开发者在不同云提供商中的偏好和经验，特别是针对最大的云提供商：亚马逊网络服务 (AWS)、微软 Azure 和 Google Cloud。对于那些部署到没有虚拟化的服务器的开发者，我们还提供了“裸金属服务器”的额外选项。
与往年类似，近一半的受访者 (50%) 将 Go 程序部署到亚马逊网络服务。紧随其后的是自有的或公司拥有的服务器 (37%)，以及 Google Cloud (30%)。在大型组织工作的受访者比在中小组织工作的受访者更有可能部署到自有的或公司拥有的服务器 (48% 对 34%)。他们也比中小组织更有可能部署到微软 Azure (25% 对 12%)。
最常用的云服务是 AWS Elastic Kubernetes Service (41%)、AWS EC2 (39%) 和 Google Cloud GKE (29%)。虽然我们看到 Kubernetes 的使用率随着时间的推移而增加，但这是我们第一次看到 EKS 的使用率超过 EC2。总体而言，Kubernetes 产品是 AWS、Google Cloud 和 Azure 中最受欢迎的服务，其次是虚拟机，然后是无服务器产品。Go 在容器化和微服务开发方面的优势自然与 Kubernetes 日益增长的受欢迎程度相契合，因为它为部署和管理这些类型的应用程序提供了一个高效且可扩展的平台。
我们向将 Go 代码部署到前三大云提供商（亚马逊网络服务、Google Cloud 和微软 Azure）的受访者提出了一个后续问题，询问他们最喜欢将 Go 代码部署到每个云的原因。不同提供商中最受欢迎的回答实际上是 Go 的性能和语言特性，而不是与云提供商相关的某个方面。
其他常见的原因包括：
- 与特定云提供商的熟悉程度与其他云相比
- 在特定云提供商上部署 Go 应用程序的便捷性
- 云提供商的 Go API/SDK 易于使用
- API/SDK 文档齐全
除了熟悉度之外，最受欢迎的几点突显了提供一流的 Go 支持以满足开发者期望的重要性。
受访者表示他们对所使用的云提供商没有什么特别喜欢的方面也相当普遍。根据之前版本的调查中收到的文字回复，这通常意味着他们没有直接与云交互。特别是，使用微软 Azure 的受访者表示“没有”是他们最喜欢的东西的可能性要大得多 (51%)，而 AWS (27%) 或 Google Cloud (30%) 则较低。
AI 助手
Go 团队推测，AI 助手有潜力将开发者从繁琐重复的任务中解放出来，使他们能够专注于更具创造性和更有价值的工作方面。为了深入了解 AI 助手最有益的领域，我们在调查中设置了一个部分来识别常见的开发者重复性工作。
大多数受访者 (70%) 在使用 Go 进行开发时使用了 AI 助手。AI 助手最常见的用途是基于 LLM 的代码补全 (35%)。其他常见回答包括编写测试 (29%)、从自然语言描述生成 Go 代码 (27%) 和头脑风暴想法 (25%)。还有相当一部分受访者 (30%) 在过去一个月中没有使用任何 LLM 助手。
将这些结果与我们 2023 年下半年的调查结果进行比较时，一些结果脱颖而出。在该调查中，我们询问受访者最希望看到 AI/ML 为 Go 开发者提供支持的 5 大用例是什么。尽管在本次调查中引入了一些新的回答选项，我们仍然可以对受访者表示希望获得 AI 支持的用例与他们的实际使用情况进行大致比较。在之前的调查中，编写测试是最期望的用例 (49%)。而在我们最新的 2024 年下半年调查中，大约 29% 的受访者在过去一个月中将 AI 助手用于此目的。这表明当前的产品未能满足开发者在编写测试方面的需求。同样，在 2023 年，47% 的受访者表示他们希望在编码时获得最佳实践建议，而一年后只有 14% 的受访者表示他们将 AI 助手用于此用例。46% 的受访者表示他们希望在编码时帮助捕获常见错误，而只有 13% 的受访者表示他们将 AI 助手用于此目的。这可能表明当前的 AI 助手尚未为这些任务做好充分准备，或者它们尚未很好地集成到开发者工作流程或工具中。
看到 AI 在从自然语言生成 Go 代码和头脑风暴方面的使用率如此之高也令人惊讶，因为之前的调查并未表明这些是用例中高度期望的功能。这些差异可能有多种解释。虽然之前的受访者最初可能并未明确地希望 AI 进行代码生成或头脑风暴，但他们可能倾向于使用这些功能，因为它们与当前生成式 AI 的优势相符——自然语言处理和创意文本生成。我们还应该记住，人们未必能很好地预测自己的行为。
我们还发现不同群体在回答这个问题时存在一些显著差异。中小组织的受访者使用 LLMs 的可能性略高 (75%)，而大型组织的受访者较低 (66%)。这可能有多种原因，例如，大型组织可能有更严格的安全和合规要求，并对 LLM 编码助手的安全性、数据泄露的可能性或是否符合特定行业法规感到担忧。他们可能还已经投资了其他开发者工具和实践，这些工具和实践已经为开发者生产力提供了类似的好处。
Go 开发经验少于 2 年的开发者更有可能使用 AI 助手 (75%)，而 Go 开发经验 5 年以上的开发者则较低 (67%)。经验较少的 Go 开发者也更有可能将它们用于更多任务，平均为 3.50 个任务。尽管所有经验水平的开发者都倾向于使用基于 LLM 的代码补全，但经验较少的 Go 开发者更有可能将 Go 用于与学习和调试相关的更多任务，例如解释一段 Go 代码的功能、解决编译器错误以及调试 Go 代码中的故障。这表明 AI 助手目前对那些不太熟悉 Go 的开发者提供了最大的效用。我们不知道 AI 助手如何影响学习或开始一个新的 Go 项目，这是我们未来想要研究的问题。然而，所有经验水平的开发者对他们的 AI 助手的满意度相似，约为 73%，因此新的 Go 开发者尽管使用 AI 助手更频繁，但对它们的满意度并没有更高。
对于报告使用 AI 助手完成至少一项与编写 Go 代码相关的任务的受访者，我们提出了一些后续问题，以了解更多关于他们使用 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（Single Instruction, Multiple Data）是一种并行处理类型，它允许单个 CPU 指令同时操作多个数据点。这有助于处理涉及大型数据集和重复操作的任务，常用于优化游戏开发、数据处理和科学计算等领域的性能。在本节调查中，我们旨在评估受访者对 Go 中原生 SIMD 支持的需求。
大多数受访者 (89%) 表示他们至少有时在性能优化至关重要的项目上工作。40% 的受访者表示他们至少有一半时间在这样的项目上工作。不同组织规模和经验水平的受访者均持这一观点，这表明性能对大多数开发者来说是一个重要问题。
大约一半的受访者 (54%) 表示他们至少对 SIMD 的概念有所了解。使用 SIMD 通常需要对计算机架构和低级编程概念有更深入的理解，因此毫不奇怪，我们发现经验较少的开发者不太熟悉 SIMD。经验更丰富且至少有一半时间在性能关键型应用程序上工作的受访者最有可能熟悉 SIMD。
对于那些至少对 SIMD 有些了解的受访者，我们提出了一些后续问题，以了解 Go 中缺乏原生 SIMD 支持对他们的影响。超过三分之一的受访者（约 37%）表示受到了影响。17% 的受访者表示他们的项目性能受到了限制，15% 的受访者表示他们不得不使用其他语言而不是 Go 来实现他们的目标，13% 的受访者表示他们不得不使用非 Go 库，而他们原本更希望使用 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 开发者社区。
除了 Go 的经验年限外，我们还测量了专业编码经验年限。我们的受众往往是相当有经验的一群人，26% 的受访者拥有 16 年或以上的专业编码经验。
自选群体比随机抽样群体更有经验，29% 的受访者拥有 16 年或以上的专业经验。这表明我们的自选群体通常比随机抽样群体更有经验，这有助于解释我们在该群体中看到的一些差异。
我们发现 81% 的受访者是全职受雇。当我们查看我们的单独样本时，我们发现来自 VS Code 的受访者群体中存在一个微小但显著的差异，他们成为学生的可能性略高。考虑到 VS Code 是免费的，这也很合理。
与往年类似，Go 最常见的用例是 API/RPC 服务 (75%) 和命令行工具 (62%)。经验更丰富的 Go 开发者报告使用 Go 构建了更广泛的应用程序。这一趋势在所有类型的应用程序或服务类别中都保持一致。我们没有发现受访者根据其组织规模构建的应用程序存在任何显著差异。来自 VS Code 和 GoLand 的随机样本的受访者也没有表现出显著差异。
公司统计数据
我们从来自各种不同组织的受访者那里听取了意见。大约 29% 的受访者在拥有 1001 名或以上员工的大型组织工作，25% 来自拥有 101-1000 名员工的中型组织，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 团队)
下一篇文章：Go 1.24 已发布！
上一篇文章：Go Protobuf：新的 Opaque API
博客索引