Go 博客
Go 开发者调查 2024 年上半年结果
背景
本文分享了我们最近一次 Go 开发者调查的结果，该调查于 2024 年 1 月和 2 月进行。除了收集有关使用 Go 和 Go 工具的感受和挑战的信息外，我们本次调查的主要关注领域是开发者如何开始将 Go（或其他语言）用于与 AI 相关的用例，以及学习 Go 或扩展 Go 技能的开发者的具体挑战。
我们从 Go 博客以及通过 VS Code Go 插件中的随机提示招募参与者。今年，在 JetBrains 的帮助下，我们还在 GoLand IDE 中加入了随机调查提示，使我们能够招募更具代表性的 Go 开发者样本。我们共收到 6,224 份回复！衷心感谢所有为实现这一切做出贡献的人。
要点
- 开发者情绪依然高涨，93% 的受访者表示他们在过去一年对 Go 感到满意。
- 大多数受访者（80%）表示他们相信 Go 团队在维护和发展语言时会“为开发者着想”。
- 在构建 AI 驱动的应用程序和服务的受访者中，普遍认为 Go 是在生产环境中运行此类应用程序的强大平台。例如，大多数使用 AI 驱动的应用程序的受访者已经使用 Go 或希望将 AI 工作负载迁移到 Go，而开发者遇到的最严重挑战与库和文档生态系统有关，而不是与核心语言和运行时有关。也就是说，目前最常见的入门路径以 Python 为中心，导致许多组织在迁移到更适合生产环境的语言之前，首先使用 Python 进行 AI 工作。
- 受访者构建的最常见的 AI 驱动的服务包括摘要工具、文本生成工具和聊天机器人。回复表明，许多用例面向内部，例如经过组织内部文档训练的聊天机器人，旨在回答员工的问题。我们推测，组织有意从内部用例开始，以便在内部发展 LLM 的专业知识，同时避免 AI 代理在意外行为时可能造成的公众尴尬。
- 缺乏时间或机会是受访者在实现 Go 相关学习目标方面遇到的最常见挑战，这表明在没有明确目标或商业案例的情况下，语言学习很难优先考虑。下一个最常见的挑战是在来自其他语言生态系统时学习 Go 特定的新最佳实践、概念和习惯用法。
内容
开发者情绪
调查显示，总体满意度仍然很高，93% 的受访者表示他们在过去一年对 Go 非常满意或比较满意。考虑到我们的受众是自愿参加调查的人，这并不令人惊讶。但即使是在从 VS Code 和 GoLand 中随机抽取的样本中，我们仍然看到类似的满意度水平（92%）。尽管确切的百分比在不同调查之间略有波动，但我们没有看到与 2023 年下半年（满意度为 90%）相比有任何统计学上的显著差异。
信任
今年，我们引入了一个衡量开发者信任的新指标。这是一个实验性问题，随着我们对受访者如何理解该问题的了解不断深入，它的措辞可能会随着时间而改变。由于这是我们第一次提出这个问题，我们没有前几年的数据来为我们的结果提供背景。我们发现，80% 的受访者表示他们有点或非常同意他们信任 Go 团队会为像他们这样的用户着想。Go 经验超过 5 年的受访者比 Go 经验不足 2 年的受访者更倾向于同意（83% 对 77%）。这可能反映了 幸存者偏差，即更信任 Go 团队的人更有可能继续使用 Go，或者可能反映了信任是如何随着时间推移而校准的。
社区满意度
在过去一年中，近三分之一的受访者（32%）表示他们在线上或线下活动中参与了 Go 开发者社区。Go 开发者经验越丰富，越有可能参与社区活动，并且对社区活动的总体满意度越高。虽然我们不能从这些数据中得出因果关系，但我们确实看到了社区满意度与 Go 的总体满意度之间存在正相关关系。这可能是因为参与 Go 社区通过增加社交互动或技术支持来提高满意度。总的来说，我们还发现，经验较少的受访者在过去一年中参与活动的可能性较低。这可能意味着他们还没有发现活动或找到参与的机会。
最大的挑战
多年来，这份调查一直在询问参与者在使用 Go 时遇到的最大挑战。这始终以开放式文本框的形式出现，并引发了各种各样的回复。在本轮调查中，我们引入了一个封闭式问题的形式，我们在其中提供了前几年的最常见的写字回复。受访者随机看到开放式问题或封闭式问题。封闭式问题可以帮助我们验证我们对这些回复的以往解释，同时也可以让我们听到更多 Go 开发者的声音：今年看到封闭式问题的参与者回答问题的可能性比看到开放式问题的参与者高 2.5 倍。更多回复的数字缩小了我们的误差范围，并提高了我们在解释调查结果时的信心。
在封闭式问题中，只有 8% 的受访者选择了“其他”，这表明我们通过回复选项涵盖了大多数常见的挑战。有趣的是，13% 的受访者表示他们在使用 Go 时没有遇到任何挑战。在开放式文本问题版本中，只有 2% 的受访者给出了这个答案。封闭式问题中的最常见回复是学习如何有效地编写 Go（15%）和错误处理的冗长性（13%）。这与我们在开放式文本问题中看到的情况一致，其中 11% 的回复提到了学习 Go、学习最佳实践或文档问题作为他们最大的挑战，另外 11% 的回复提到了错误处理。
看到封闭式问题的受访者还会收到一个开放式文本问题的后续问题，让他们有机会告诉我们更多关于他们遇到的最大挑战的信息，以防他们想要提供更多细致入微的答案、额外的挑战或任何他们认为重要的信息。最常见的回复提到了 Go 的类型系统，并且经常特别要求在 Go 中使用枚举、可选类型或求和类型。我们通常没有获得关于这些请求的太多背景信息，但我们怀疑这是由于最近关于枚举的一些提案和社区讨论、越来越多的人来自其他语言生态系统（这些生态系统中这些功能很常见），或者人们期望这些功能会减少编写样板代码。关于类型系统的一个更全面的评论解释如下
“这些不是什么大挑战，但更多的是我在语言中缺少的便利功能。有办法解决这些问题，但不用费心去想就好了。
求和类型/封闭枚举可以模拟，但很麻烦。当与仅对响应中的特定元素/字段具有有限值集的 API 交互时，并且超出该值集的值是错误时，这是一个非常实用的功能。它有助于验证并在入口点捕获问题，并且通常可以直接从 API 规范（如 JSON Schema、OpenAPI 或 XML Schema Definitions）生成。
我不介意错误检查的冗长性，但指针的空值检查很繁琐，尤其是在我需要深入到指针字段的嵌套结构时。一些形式的可选/结果类型或追溯指针链并简单地返回一个空值（而不是触发运行时恐慌）的功能将受到赞赏。”
开发者环境
与往年一样，大多数调查受访者在 Linux（61%）和 macOS（58%）系统上使用 Go 进行开发。尽管这些数字与往年相比变化不大，但我们在自选样本中发现了一些有趣的差异。来自 JetBrains 和 VS Code 的随机样本组在 Windows 上进行开发的可能性更高（分别为 31% 和 33%），而自选组的可能性更低（19%）。我们不知道为什么自选组如此不同，但我们推测，因为他们很可能是在阅读 Go 博客时遇到的调查，这些受访者可能是社区中最投入和经验丰富的开发者。他们对操作系统的偏好可能反映了核心开发团队（他们通常在 Linux 和 macOS 上进行开发）的历史优先级。值得庆幸的是，我们有来自 JetBrains 和 VS Code 的随机样本，可以提供更具代表性的开发者偏好视图。
作为对 17% 在 WSL 上进行开发的受访者的后续调查，我们询问了他们使用的是哪个版本。93% 在 WSL 上进行开发的受访者使用的是版本 2，因此，微软的 Go 团队决定将他们的工作重点放在 WSL2 上。
鉴于我们的两个样本群体是从 VS Code 或 GoLand 内部招募的，他们对偏爱这些编辑器存在强烈的偏见。为了避免结果出现偏差，我们在此仅显示来自自选组的数据。与前几年类似，Go 开发者调查受访者中最常用的代码编辑器仍然是 VS Code (43%) 和 GoLand (33%)。我们没有发现与 2023 年中旬相比有任何统计学上的显著差异（分别为 44% 和 31%）。
鉴于 Go 在云开发和容器化工作负载中的普及，Go 开发者主要部署到 Linux 环境（93%）并不奇怪。我们没有发现与去年相比有任何重大变化。
Go 是一种流行的现代云开发语言，因此我们通常会包含调查问题，以帮助我们了解 Go 开发者使用哪些云平台以及他们对三个最流行的平台的满意度：亚马逊网络服务 (AWS)、微软 Azure 和谷歌云。本节仅向表示将 Go 用于其主要工作的受访者显示，约占总受访者的 76%。98% 的看到此问题的受访者正在开发与云服务集成的 Go 软件。超过一半的受访者使用 AWS (52%)，而 27% 的受访者将 GCP 用于其 Go 开发和部署。对于 AWS 和 Google Cloud，我们没有发现小公司和大公司在使用这两个提供商的可能性方面存在任何差异。微软 Azure 是唯一一个在大型组织（员工人数超过 1000 人的公司）中比小型公司更有可能被使用的云提供商。我们没有发现基于组织规模的任何其他云提供商的用法方面存在任何显著差异。
使用 Go 与 AWS 和 Google Cloud 的满意度率均为 77%。从历史上看，这些比率大体相同。与往年一样，微软 Azure 的满意度率较低 (57%)。
资源和安全优先级
为了帮助确定 Go 团队工作的优先级，我们希望了解使用 Go 的团队面临的资源成本和安全问题。大约一半使用 Go 工作的受访者报告称，他们在过去一年中至少遇到过一个资源成本问题 (52%)。编写和维护 Go 服务的工程成本更为普遍 (28%)，其次是对运行 Go 服务成本的担忧 (10%) 或两者大致相同 (12%)。我们没有发现小型组织和大公司在资源问题方面存在任何显著差异。为了解决对资源成本的担忧，Go 团队正在继续优化 Go 并增强配置文件引导优化 (PGO)。
对于安全优先级，我们要求受访者告诉我们他们最关心的三个问题。在那些确实有安全问题的人中，总的来说，首要问题是不安全的编码实践 (42%)，其次是系统配置错误 (29%)。我们的主要结论是，受访者尤其对帮助他们在编写代码时查找和修复潜在安全问题的工具感兴趣。这与我们从之前关于开发人员如何查找和解决安全漏洞的研究中了解到的内容相一致。
性能工具
本节的目标是衡量受访者对诊断性能问题的难易程度的看法，并确定此任务的难易程度是否取决于他们对编辑器或 IDE 的使用。具体而言，我们想知道从命令行诊断性能问题是否更困难，以及我们是否应该投资改进 VS Code 中的性能诊断工具集成，以简化此任务。在我们的分析中，我们展示了偏好 VS Code 或 GoLand 的受访者之间的比较，以突出显示我们对使用 VS Code 与另一个常用编辑器相比的体验的了解。
我们首先问了一个关于受访者使用 Go 的各种工具和技术的一般问题，以便进行一些比较。我们发现，只有 40% 的受访者使用工具来提高代码性能或效率。我们没有发现基于编辑器或 IDE 偏好的任何显著差异，也就是说，VS Code 用户和 GoLand 用户使用工具来提高代码性能或效率的可能性大致相同。
大多数受访者 (73%) 告诉我们，识别和解决性能问题至少是中等重要性。同样，我们没有发现 GoLand 和 VS Code 用户在认为诊断性能问题的重要性方面存在任何显著差异。
总体而言，受访者并没有发现诊断性能问题很容易，30% 的受访者报告说这有些困难或非常困难，46% 的受访者说这既不简单也不难。与我们的假设相反，VS Code 用户并没有更有可能在诊断性能问题时报告挑战，而其他受访者则没有。那些使用命令行诊断性能问题的用户，无论他们偏爱哪个编辑器，也没有报告说此任务比那些使用 IDE 的用户更具挑战性。我们观察到的唯一显著因素是多年的经验，经验不足的 Go 开发人员发现诊断性能问题的难度总体上高于经验丰富的 Go 开发人员。
为了回答我们最初的问题，大多数开发人员发现，无论他们偏爱哪个编辑器或工具，在 Go 中诊断性能问题都很困难。对于在 Go 中拥有不到两年经验的开发人员来说尤其如此。
我们还包括一个后续问题，针对那些将诊断性能问题评定为至少略微重要的受访者，以了解哪些问题对他们来说最重要。延迟、总内存和总 CPU 是最主要的关注点。对于这些领域的显著性，可能存在多种解释。首先，它们是可衡量的，并且可以轻松地转换为商业成本。其次，总内存和 CPU 使用率代表了物理约束，需要硬件升级或软件优化才能改进。此外，延迟、总内存和总 CPU 更容易由开发人员管理，并且会影响甚至简单的服务。相反，GC 性能和内存分配可能只在极少数情况下或对于极其繁重的负载相关。此外，延迟是用户最容易看到的指标，因为高延迟会导致服务缓慢和用户不满意。
了解 Go 的 AI 用例
我们之前的调查询问 Go 开发人员他们对生成式人工智能系统的早期体验。为了在本轮调查中更深入地了解，我们提出了一些与人工智能相关的問題，以了解受访者是如何构建人工智能驱动的（更具体地说，是 LLM 驱动的）服务的。我们发现，一半的调查受访者 (50%) 在构建或探索人工智能驱动的服务的组织中工作。其中，略高于一半 (56%) 表示他们参与了向其组织的服务添加人工智能功能。我们剩下的与人工智能相关的問題只向这部分受访者展示。
请谨慎将这些参与者的回应推广到 Go 开发者的整体人口。由于只有大约四分之一的调查受访者正在使用人工智能驱动的服务，我们建议使用这些数据来了解该领域的早期采用者，前提是早期采用者往往与最终采用一项技术的多数人有所不同。例如，我们预计该受众正在尝试比一两年后更多的模型和 SDK，并且遇到了更多关于将这些服务集成到其现有代码库中的挑战。
在专业使用生成式人工智能 (GenAI) 系统的 Go 开发者中，绝大多数 (81%) 报告使用 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列开源模型也获得了高度采用，大多数受访者 (53%) 使用了 Llama、Mistral 或其他 OSS 模型中的至少一个。我们看到一些早期证据表明，大型组织（1000 多名员工）使用 OpenAI 模型的可能性略低 (74% vs. 83%)，而使用其他专有模型的可能性略高 (22% vs. 11%)。但是，我们没有发现任何证据表明基于组织规模的 OSS 模型采用率存在差异 - 小型公司和大型企业都显示出较小比例的采用 OSS 模型 (分别为 51% 和 53%)。总体而言，我们发现大多数受访者更喜欢使用开源模型 (47%)，只有 19% 的人更喜欢专有模型；37% 的人表示他们没有偏好。
受访者正在构建的最常见服务类型包括摘要工具 (56%)、文本生成工具 (55%) 和聊天机器人 (46%)。开放式文本回复表明，许多用例是面向内部的，例如针对组织内部文档进行训练的聊天机器人，旨在回答员工问题。受访者对面向外部的人工智能功能提出了若干担忧，最主要的是由于可靠性 (例如，我的问题中的细微变化是否会导致截然不同的结果？) 和准确性 (例如，结果是否值得信赖？) 问题。这些回复中一个有趣的主题是，在不采用人工智能工具的风险（因此在生成式人工智能未来可能变得必要时失去潜在的竞争优势）与因在高度关键的客户面对面领域使用未经测试的人工智能而导致负面宣传或违反法规/法律的风险之间存在一种紧张关系。
我们发现 Go 已经在 GenAI 领域得到应用，并且对 Go 的需求不断增长。大约三分之一正在构建 AI 功能的受访者告诉我们，他们已经在各种 GenAI 任务中使用 Go，包括原型设计新功能和将服务与 LLM 集成。在两个我们认为 Go 特别适合的领域，这些比例略有上升：用于 ML/AI 系统的数据管道（37%）和用于 ML/AI 模型的托管 API 端点（41%）。除了这些（可能是早期）采用者之外，我们还发现大约四分之一的受访者 *希望* 在这些类型的用途上使用 Go，但目前被某些因素阻碍。在探讨受访者最初为什么要使用 Go 完成这些任务的原因之后，我们将很快回到这些阻碍因素。
使用 Go 与生成式 AI 系统的原因
为了帮助我们了解开发人员希望从在他们的 AI/ML 服务中使用 Go 获得哪些好处，我们询问了开发人员为什么他们认为 Go 是该领域的不错选择。大多数受访者（61%）提到了 Go 的一个或多个核心原则或特性，例如简洁性、运行时安全性、并发性或单二进制部署。三分之一的受访者提到了他们对 Go 的熟悉程度，包括如果可以避免的话，他们希望避免引入新的语言。最常见的回复是 Python 的各种挑战（特别是对于运行生产服务），占比 14%。
“我认为该语言提供的健壮性、简洁性、性能和原生二进制文件使其成为 AI 工作负载的更强大选择。” — 一家大型组织的开源 Go 开发人员，拥有不超过 1 年的经验
“我们希望在整个组织中尽可能保持技术栈的同质性，以使每个人更容易在所有领域进行开发。由于我们已经使用 Go 编写了所有后端，因此我们有兴趣能够用 Go 编写 ML 模型部署，并避免必须用其他语言（如 Python）为日志记录、监控等重新编写部分堆栈。” — 一家中型组织的专业 Go 开发人员，拥有 5-7 年的经验
“Go 更适合我们运行 API 服务器和工作池中的后台任务。Go 的较低资源使用率使我们能够在不使用更多资源的情况下增长。我们发现，Go 项目更容易随着时间的推移进行维护，无论是代码更改还是更新依赖项。我们将模型作为用 Python 编写的独立服务运行，并在 Go 中与它们交互。” — 一家大型组织的专业 Go 开发人员，拥有 5-7 年的经验
看来，在对 ML/AI 感兴趣的 Go 开发人员中，普遍存在这样一种共识：1）Go 本质上是该领域的良好语言（如上所述的原因），以及 2）组织已经投资了 Go 后，不愿意引入新的语言（这一点可以合理地推广到任何语言）。一些受访者还表达了对 Python 的失望，原因包括类型安全性、代码质量和具有挑战性的部署。
使用 Go 与 GenAI 系统时的挑战
受访者在目前阻止他们使用 Go 与 AI 功能服务方面高度一致：生态系统以 Python 为中心，他们最喜欢的库/框架都在 Python 中，入门文档假设熟悉 Python，以及探索这些模型的数据科学家或研究人员已经熟悉 Python。
“Python 似乎拥有所有库。例如，PyTorch 被广泛用于运行模型。如果有 Go 中的框架来运行这些模型，我们更愿意这样做。” — 一家大型组织的专业 Go 开发人员，拥有 2-4 年的经验
“Python 工具在开箱即用方面更加成熟和可用，使其成为实施成本明显更低的工具。” — 一家小型组织的专业 Go 开发人员，拥有 2-4 年的经验
“[The] Go 世界缺少很多 AI 库。如果我有一个 LLM PyTorch 模型，我甚至无法为其提供服务（或者我不知道如何做到这一点）。使用 Python，它基本上只是一些代码。” — 一家小型组织的专业 Go 开发人员，拥有不超过 1 年的经验
这些发现与我们之前观察到的 Go 开发人员认为 Go *应该* 是构建生产就绪 AI 服务的绝佳语言相吻合：只有 3% 的受访者表示，Go 的某些特定问题阻碍了他们的前进道路，只有 2% 提到了与 Python 的特定互操作性挑战。换句话说，开发人员面临的大多数障碍可以在模块和文档生态系统中解决，而无需对核心语言或运行时进行更改。
我们还询问了调查参与者是否已经在 GenAI 中使用 Python，以及如果是，他们是否更愿意使用 Go。那些说他们更愿意使用 Go 而不是 Python 的受访者还收到了一封关于什么可以让他们将 Go 与 GenAI 系统集成的后续问题。
大多数受访者（62%）报告说他们已经使用 Python 来与生成式 AI 模型集成；在这些人中，57% 更愿意使用 Go。鉴于我们的调查对象都是 Go 开发人员，因此我们应该预计这将是今天每个生态系统的现状下，对有兴趣从 Python 转移到 Go 完成 GenAI 任务的总体开发人员比例的近似上限。
在那些已经使用 Python 但更愿意使用 Go 的受访者中，绝大多数（92%）表示，Python 库的 Go 等效库的可用性将使他们能够将 Go 与 GenAI 系统集成。然而，在解释这个结果时我们应该谨慎；开放式文本回复以及与正在 GenAI 服务上工作的开发人员进行的单独的一组情境访谈描述了围绕 GenAI 的以 Python 为中心的生态系统；不仅 Go 与 Python 生态系统相比缺少很多库，而且人们认为对 Go 库的投资水平较低，文档和示例主要使用 Python，并且该领域工作的专家网络已经习惯于 Python。使用 Python 进行实验和构建概念证明几乎肯定会继续下去，而 Python 库的 Go 变体（例如，pandas）只是开发人员在尝试从 Python 移植到 Go 时遇到的第一个障碍。库和 SDK 是必要的，但它们本身可能不足以构建用于生产 ML/AI 应用程序的强大 Go 生态系统。
此外，与正在构建 AI 功能服务的 Go 开发人员进行的情境访谈表明，从 Go 调用 API 不是主要问题，特别是对于托管模型（例如，GPT-4 或 Gemini）。在 Go 中构建、评估和托管自定义模型被认为具有挑战性（主要是由于缺乏支持 Python 中的框架和库），但访谈参与者区分了业余爱好者用例（例如，在家里玩弄自定义模型）和商业用例。业余爱好者用例主要使用 Python，原因如上所述，但商业用例更多地关注在调用托管模型时的可靠性、准确性和性能。这是一个 Go 可以*无需* 构建大型 ML/AI/数据科学库生态系统就可以大放异彩的领域，尽管我们预计开发人员仍然会受益于文档、最佳实践指南和示例。
由于 GenAI 领域非常新颖，最佳实践仍在确定和测试之中。与开发人员进行的初步情境访谈表明，他们的目标之一是为 GenAI 成为竞争优势的未来做好准备；通过现在在这个领域进行一些投资，他们希望减轻未来的风险。他们仍在努力了解 GenAI 系统可能对哪些方面有所帮助以及投资回报率（如果有的话）可能是什么样。由于这些未知因素，我们的早期数据表明，组织（特别是科技行业以外的组织）可能不愿在这个领域做出长期承诺，而是会采取精益或灵活的方法，直到出现具有明确效益的可靠用例，或者他们的行业同行开始在这个领域进行大量公开投资。
学习挑战
为了改善学习 Go 的体验，我们希望从没有经验的 Go 开发人员以及那些可能已经掌握了基础知识的人那里了解他们认为满足他们的学习目标的最大挑战。我们还希望从主要专注于帮助其他人开始使用 Go 而不是自己的学习目标的开发人员那里了解他们可能对他们在引导开发人员时遇到的常见挑战的一些见解。
只有 3% 的受访者表示他们目前正在学习 Go 的基础知识。考虑到我们大多数调查受访者至少有一年的 Go 经验，这并不令人惊讶。与此同时，40% 的受访者表示他们已经学习了基础知识，但希望学习更高级的主题，另外 40% 的受访者表示他们帮助其他开发人员学习 Go。只有 15% 的人说他们没有与 Go 相关的任何学习目标。
当我们查看更细粒度的 Go 经验时间段时，我们发现，30% 使用 Go 不到三个月的开发人员表示他们正在学习 Go 的基础知识，而他们中大约三分之二的人说他们已经学习了基础知识。这是一个很好的证据，表明人们至少可以感觉到他们在很短的时间内就学会了 Go 的基础知识，但这同时也意味着我们没有从这些处于学习旅程初期的人那里获得很多反馈。
为了确定社区可能最需要哪种类型的学习材料，我们询问了受访者对于与软件开发相关的主题，他们更喜欢哪种类型的学习内容。他们可以选择多个选项，因此这里的数字超过了 100%。87% 的受访者表示他们更喜欢书面内容，这是迄今为止最受欢迎的格式。52% 的受访者表示他们更喜欢视频内容，特别是这种格式更受经验较少的开发人员的青睐。这可能表明对视频格式的学习内容的渴望正在增长。然而，经验较少的受众群体对书面内容的偏好并不低于其他群体。同时提供书面和视频格式已被证明可以提高学习成果，并且可以帮助具有不同学习偏好和能力的开发人员，这可以提高 Go 社区学习内容的可访问性。
我们询问了那些说他们有与 Go 相关的学习目标的受访者，他们实现目标的最大挑战是什么。这个问题有意地留得很宽泛，以便那些刚入门或已经掌握了基础知识的人都可以回答这个问题。我们还希望让受访者有机会告诉我们各种各样的挑战，而不仅仅是他们认为困难的主题。
压倒性的最常见挑战是缺乏时间或其他个人限制，例如学习的专注力或动力，或者（44%）。虽然我们不能给受访者更多时间，但我们应该在制作学习材料或引入生态系统中的变化时，意识到用户可能在承受着巨大的时间压力。教育者可能还有机会制作一些资源，这些资源可以以较小的部分消化或以规律的节奏进行，以保持学习者的积极性。
除了时间，最大的挑战是学习 Go 语言独有的新概念、习语或最佳实践 (11%)。特别是从 Python 或 JavaScript 转向静态类型编译语言，以及学习如何组织 Go 代码，可能尤其具有挑战性。受访者还要求提供更多示例 (6%)，包括文档和真实世界应用程序中的示例，以便从中学习。来自较大开发者社区的开发者希望能够找到更多现有的解决方案和示例。
“从 Python 这样的语言转向静态类型编译语言颇具挑战，但 Go 本身并非如此。我喜欢通过快速反馈来学习，所以 Python 的 REPL 对此非常有用。因此，现在我需要专注于阅读文档和示例才能学习。Go 的一些文档相当稀疏，可以增加更多示例。” — Go 语言使用经验少于 3 年的受访者。
“我的主要挑战是缺少企业级应用程序的示例项目。如何组织大型 Go 项目是我希望获得更多示例作为参考的内容。我想将我正在开发的当前项目重构为更模块化/更清晰的架构风格，但我发现由于缺乏示例/更明确的“文件夹/包”参考，在 Go 中很难做到这一点。” — Go 语言使用经验为 1-2 年的受访者。
“与我习惯的生态系统相比，它更小，因此在线搜索并不能产生针对特定问题的更多结果。现有的资源非常有用，我通常最终能够解决问题，只是需要多花一些时间。”— Go 语言使用经验少于 3 个月的受访者。
对于主要学习目标是帮助他人开始使用 Go 的受访者，我们询问了哪些因素可以使开发者更容易开始使用 Go。我们收到了各种各样的回复，包括文档建议、关于困难主题（例如使用指针或并发）的评论，以及将其他语言中更熟悉的特性添加到 Go 的请求。对于占回复不到 2% 的类别，我们将它们归类为“其他”回复。有趣的是，没有人提到“更多时间”。我们认为这是因为，当没有立即需要学习与 Go 相关的新事物时，时间不足或缺乏动力通常是挑战。对于那些帮助他人开始使用 Go 的人来说，可能存在这样做的商业原因，从而更容易优先考虑，因此“时间不足”不是那么大的挑战。
与之前的结果一致，16% 的帮助他人开始使用 Go 的受访者告诉我们，新的 Go 开发者将从更多现实的示例或基于项目的练习中受益。他们还看到了通过不同语言之间的比较来帮助来自其他语言生态系统的开发者的必要性。之前的研究告诉我们，使用一种编程语言的经验会干扰学习新的编程语言，尤其是在新概念和工具与开发者习惯的工具不同时。现有的资源旨在解决这个问题（只需搜索“Golang for [language] developers”即可找到示例），但对于新的 Go 开发者来说，搜索他们还没有词汇量来表达的概念可能很困难，或者这些类型的资源可能无法充分解决特定任务。在未来，我们希望进一步了解如何以及何时展示语言比较，以促进学习新概念。
这个群体报告的另一个相关需求是更多关于 Go 哲学和最佳实践的解释。学习 Go 的不同之处，以及为什么会不同，这可能会帮助新的 Go 开发者理解可能与他们之前经验不同的新概念或完成任务的方式。
人口统计
我们在每次调查周期中都问相同的人口统计问题，以便了解每年结果的比较程度。例如，如果在一次调查周期中，大多数受访者报告说他们使用 Go 的时间不到一年，那么之前的周期中的任何其他结果差异很可能源于这种主要的人口统计变化。我们还利用这些问题在群体之间进行比较，例如根据受访者使用 Go 的时间长短来比较满意度。
今年，我们对询问 Go 使用经验的方式进行了一些细微调整，以匹配 JetBrains 开发者调查。这使我们能够在调查人群之间进行比较，并便于数据分析。
我们发现，根据开发者发现调查的方式，他们的经验水平有所不同。通过 VS Code 的调查通知回复的人群的 Go 使用经验较少；我们怀疑这反映了 VS Code 在新的 Go 开发者中受欢迎程度，他们可能还没有准备好投资 IDE 许可证，因为他们还在学习。关于 Go 使用年限，从 GoLand 随机选择的受访者与通过 Go 博客自愿参与调查的人群更相似。看到这些样本之间的一致性，让我们更有信心将调查结果推广到社区的其他成员。
除了 Go 使用年限之外，今年我们还测量了专业编码经验年限。我们惊讶地发现，26% 的受访者具有 16 年或更长的专业编码经验。相比之下，2023 年 JetBrains 开发者调查受众中，大多数受访者具有 3-5 年的专业经验。具有更丰富的经验人口可能会影响回复的差异。例如，我们发现，不同经验水平的受访者在学习内容方面存在显著差异。
当我们查看不同的样本时，自愿参与调查的群体比随机选择的群体更有经验，其中 29% 的受访者具有 16 年或更长的专业经验。这表明我们的自愿参与调查的群体通常比随机选择的群体更有经验，并有助于解释我们在该群体中观察到的一些差异。
我们在本次调查周期中引入了另一个关于就业状况的人口统计问题，以帮助我们与JetBrains 的开发者调查进行比较。我们发现，81% 的受访者是全职受雇，远高于 JetBrains 调查的 63%。我们还发现，我们的人口统计数据中，学生比例明显低于 JetBrains 调查的 15% (4%)。当我们查看各个样本时，我们发现 VS Code 的受访者之间存在微不足道的差异，他们不太可能全职受雇，而更有可能成为学生。考虑到 VS Code 是免费的，这似乎很合理。
与往年类似，Go 最常见的用例是 API/RPC 服务 (74%) 和命令行工具 (63%)。我们听说 Go 的内置 HTTP 服务器和并发原语、轻松跨平台编译以及单二进制部署使 Go 成为这类应用程序的理想选择。
我们还根据受访者使用 Go 的经验水平和组织规模寻找差异。更有经验的 Go 开发者报告说，他们在 Go 中构建了更多种类的应用程序。这种趋势在每种应用程序或服务类别中都是一致的。我们没有发现根据组织规模，受访者在构建的内容方面有任何显著差异。
公司统计
我们从各种不同组织的受访者那里获得了回复。大约 27% 的受访者在拥有 1000 名或更多员工的大型组织工作，25% 的受访者来自拥有 100-1000 名员工的中型组织，43% 的受访者在拥有不到 100 名员工的小型组织工作。与往年一样，人们工作最常见的行业是技术 (48%)，其次是金融服务 (13%)。
这与过去几年的 Go 开发者调查结果在统计上没有变化，我们继续以一致的速率，从不同国家、不同规模和不同行业的组织的受访者那里获得回复。
方法
在 2021 年之前，我们主要通过 Go 博客宣布调查，该调查在 Twitter、Reddit 或 Hacker News 等各种社交频道上被报道。在 2021 年，我们引入了一种新的招募受访者方式，即使用 VS Code Go 插件随机选择用户，并向他们显示一个提示，询问他们是否愿意参加调查。这创建了一个随机样本，我们用它来比较我们传统渠道的自愿参与调查的受访者，并帮助识别自我选择偏差的潜在影响。在本次调查周期中，我们 JetBrains 的朋友慷慨地为我们提供了一个额外的随机样本，方法是提示 GoLand 用户的随机子集参加调查！
64% 的调查受访者“自愿”参加调查，这意味着他们在 Go 博客或其他社交 Go 频道上发现了调查。不关注这些频道的人不太可能从这些频道了解到调查，而且在某些情况下，他们的回复与密切关注这些频道的人不同。例如，他们可能是 Go 社区的新成员，尚未了解 Go 博客。大约 36% 的受访者是随机抽样的，这意味着他们在 VS Code (25%) 或 GoLand (11%) 中看到提示后回复了调查。在 1 月 23 日至 2 月 13 日期间，用户看到此提示的概率大约为 10%。通过检查随机抽样群体与自愿参与调查的回复的差异，以及彼此之间的差异，我们能够更有信心将调查结果推广到更广泛的 Go 开发者群体。
如何解读这些结果
在本报告中，我们使用调查回复图表来为我们的调查结果提供支持性证据。所有这些图表都使用类似的格式。标题是调查受访者看到的具体问题。除非另有说明，问题都是单选题，参与者只能选择一个回复选项；每个图表的副标题都会告诉读者问题是否允许选择多个回复选项，或者是否是一个开放式文本框，而不是一个单选题。对于开放式文本回复的图表，Go 团队成员阅读并手动对所有回复进行分类。许多开放式问题产生了各种各样的回复；为了使图表大小保持合理，我们将它们压缩到最多 10-12 个主题，其他主题都归类为“其他”。图表中显示的百分比标签四舍五入到最接近的整数（例如，1.4% 和 0.8% 都将显示为 1%），但每个条形的长度和行顺序是根据未四舍五入的值确定的。
为了帮助读者理解每个发现背后的证据权重，我们添加了误差线，显示响应的 95% 置信区间；误差线越窄，表示置信度越高。有时，两个或多个响应的误差线会有重叠，这意味着这些响应的相对顺序在统计上没有意义（即，这些响应实际上是平局）。每个图表右下角显示了包含在图表中的响应人数，格式为“n = [响应人数]”。在发现不同群体之间（例如，工作经验年限、组织规模或样本来源）的响应存在有趣差异的情况下，我们展示了差异的彩色编码细分。
结语
这就是我们半年一次的 Go 开发者调查的全部内容。感谢所有分享他们对 Go 的想法的人，以及所有帮助进行此调查的人！这对我们意义重大，真正帮助我们改进 Go。
今年，我们还很高兴地宣布即将发布此调查数据集。我们预计将在四月底分享这些匿名数据，让任何人都可以根据需要对调查响应进行切片和切块，以回答他们自己关于 Go 生态系统的问题。
更新日期：2024-05-03：我们很遗憾地需要延迟发布此数据集。我们仍在努力使之成为现实，但预计在 2024 年下半年之前无法分享。
—— Alice 和 Todd（代表 Google 的 Go 团队）
下一篇文章：使用 math/rand/v2 演化 Go 标准库
上一篇文章：更强大的 Go 执行跟踪
博客索引