背景

本文分享了我们最近一次 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，或者希望迁移到 Go 来处理他们的 AI 驱动工作负载，而开发者遇到的最严重挑战与库和文档生态系统相关，而非核心语言和运行时。尽管如此，目前最常见的入门路径是以 Python 为中心，导致许多组织在 Python 中开始 AI 驱动的工作，然后再迁移到更适合生产环境的语言。
• 受访者正在构建的最常见的 AI 驱动服务包括摘要工具、文本生成工具和聊天机器人。调查结果表明，其中许多用例是面向内部的，例如基于组织内部文档训练的聊天机器人，用于回答员工问题。我们推测，组织有意从内部用例开始，以培养 LLM 的内部专业知识，同时避免 AI 驱动代理行为意外时可能造成的公开尴尬。
• 时间或机会不足是受访者实现 Go 相关学习目标时最常提到的挑战，这表明如果没有特定的目标或业务案例，很难优先考虑语言学习。下一个最常见的挑战是学习 Go 特有的新最佳实践、概念和惯用法，特别是当来自其他语言生态系统时。

目录

• 开发者情绪
• 开发者环境
• 资源和性能优先级
• 理解 Go 的 AI 用例
• 学习挑战
• 人口统计
• 企业信息
• 方法论
• 结语

开发者情绪

总体满意度在本次调查中仍然很高，93% 的受访者表示在过去一年中对 Go 感到“比较满意”或“非常满意”。这并不令人意外，因为我们的受众是那些自愿参加调查的人。但即使是在从 VS Code 和 GoLand 随机抽样的受访者中，我们也看到了相似的满意率（92%）。尽管具体百分比在不同调查中略有波动，但与 2023 年下半年的调查相比，我们没有发现任何统计学上的显著差异，当时满意率为 90%。

信任

今年我们引入了一个新的指标来衡量开发者信任度。这是一个实验性问题，随着我们对受访者如何解读它的了解越来越多，其措辞可能会发生变化。由于这是我们第一次提出这个问题，我们没有往年的数据来提供背景信息。我们发现，80% 的受访者“比较同意”或“非常同意”他们信任 Go 团队会为像他们一样的用户做出最好的选择。拥有 5 年以上 Go 经验的受访者比拥有不到 2 年经验的受访者（77%）更倾向于同意（83%）。这可能反映了 幸存者偏差，即更信任 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）生成。

我完全不介意错误检查的冗长，但指针的 nil 检查会变得乏味，尤其是当我需要深入研究指针字段的深层嵌套结构时。如果能提供某种 Optional/Result 类型，或者能够遍历指针链并简单地获得 nil 而不是触发运行时恐慌，那将受到赞赏。”

开发者环境

与往年一样，大多数调查受访者在 Linux（61%）和 macOS（58%）系统上使用 Go 进行开发。尽管每年的数字变化不大，但我们在自选样本中看到了一些有趣的差异。来自 JetBrains 和 VS Code 的随机抽样组在 Windows 上的开发比例更高（分别为 31% 和 33%），而自选组则较低（19%）。我们不确切知道自选组为何如此不同，但我们推测，由于他们很可能从 Go Blog 上看到了调查，因此这些受访者是社区中最敬业、最有经验的开发者。他们的操作系统偏好可能反映了核心开发团队的历史优先事项，他们通常在 Linux 和 macOS 上进行开发。值得庆幸的是，我们有来自 JetBrains 和 VS Code 的随机样本来提供更具代表性的开发者偏好视角。

作为对开发 WSL 的 17% 受访者的后续调查，我们询问了他们使用的版本。93% 的 WSL 受访者使用 2 版本，因此未来，微软的 Go 团队已决定将其工作重点放在 WSL2 上。

考虑到我们的两个样本群体是从 VS Code 或 GoLand 中招募的，他们强烈倾向于偏好那些编辑器。为了避免结果失衡，我们仅在此处展示来自自选群体的数据。与往年类似，Go 开发者调查受访者中最常用的代码编辑器仍然是 VS Code（43%）和 GoLand（33%）。与 2023 年中期相比，我们没有看到任何统计学上的显著差异（分别为 44% 和 31%）。

鉴于 Go 在云开发和容器化工作负载中的普遍性，Go 开发者主要部署到 Linux 环境（93%）也就不足为奇了。我们没有看到与去年相比有任何重大变化。

Go 是现代基于云的开发的热门语言，因此我们通常会包含调查问题，以帮助我们了解 Go 开发者正在使用哪些云平台，以及他们对三个最受欢迎平台：Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud 的满意度。此部分仅显示给那些表示使用 Go 进行主要工作的受访者，约占总受访者的 76%。看到此问题的受访者中有 98% 从事与云服务集成的 Go 软件工作。一半以上的受访者使用 AWS（52%），而 27% 使用 GCP 进行 Go 开发和部署。对于 AWS 和 Google Cloud，我们没有看到小型或大型公司在使用任一提供商的可能性方面存在差异。Microsoft Azure 是唯一一个在大型组织（员工超过 1000 人）中使用的可能性显著高于小型公司的云提供商。我们没有看到任何其他云提供商在组织规模方面存在使用上的显著差异。

使用 Go 的 AWS 和 Google Cloud 的满意率均为 77%。从历史上看，这些比率大致相同。与往年一样，Microsoft Azure 的满意率较低（57%）。

资源和安全优先级

为了帮助优先确定 Go 团队的工作，我们想了解使用 Go 的团队的顶级资源成本和安全顾虑。在工作中会使用 Go 的受访者中，大约一半（52%）报告称在过去一年中至少有一项资源成本顾虑。编写和维护 Go 服务的工程成本（28%）比运行 Go 服务的成本（10%）或两者大致相等（12%）更常见。我们没有发现小型和大型组织在资源顾虑方面存在显著差异。为了解决资源成本问题，Go 团队将继续优化 Go 并增强剖面引导优化 (PGO)。

关于安全优先级，我们要求受访者列出最多三项他们最关心的内容。在确实有安全顾虑的人中，总体而言，最主要的顾虑是安全编码实践（42%），其次是系统配置错误（29%）。我们的主要收获是，受访者特别对有助于在编写代码时发现和修复潜在安全问题的工具感兴趣。这与我们之前关于开发者如何发现和解决安全漏洞的研究结果一致。

性能工具

本节的目标是衡量受访者认为诊断性能问题的难易程度，并确定这项任务是更难还是更容易，这取决于他们的编辑器或 IDE 使用情况。具体来说，我们想知道从命令行诊断性能问题是否更困难，以及我们是否应该投资于改进 VS Code 中性能诊断工具的集成，以使这项任务更容易。在我们的分析中，我们展示了偏好 VS Code 或 GoLand 的受访者之间的比较，以突出我们对使用 VS Code 与其他常用编辑器体验的了解。

我们首先就受访者使用的不同类型的工具和技术进行了通用性问题，以便进行比较。我们发现只有 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 开发者关于他们使用生成式 AI 系统的早期经验。为了在本周期中进行更深入的了解，我们提出了一些与 AI 相关的问题，以了解受访者如何构建 AI 驱动的（更具体地说，是 LLM 驱动的）服务。我们发现，一半的调查受访者（50%）在构建或探索 AI 驱动的服务的组织工作。其中，略高于一半（56%）的人表示他们参与了将 AI 功能添加到其组织的服务中。我们剩余的 AI 相关问题仅显示给这部分受访者。

请谨慎地将这些参与者的回复推广到 Go 开发者的整体人群。由于只有约四分之一的调查受访者在使用 AI 驱动的服务，我们建议使用这些数据来理解该领域的早期采用者，但要提醒的是，早期采用者通常与最终采用一项技术的绝大多数人有所不同。例如，我们预计这个受众将尝试比一两年后更多的模型和 SDK，并遇到更多与将这些服务集成到现有代码库相关的挑战。

在使用生成式 AI (GenAI) 系统的 Go 开发者受众中，绝大多数（81%）报告使用 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列开源模型也得到了广泛采用，大多数受访者（53%）至少使用 Llama、Mistral 或其他 OSS 模型之一。我们有一些早期证据表明，大型组织（1000+ 名员工）不太可能使用 OpenAI 模型（74% 对比 83%），而更可能使用其他专有模型（22% 对比 11%）。然而，我们没有发现任何证据表明采用 OSS 模型基于组织规模存在差异——较小的公司和大型企业都显示出使用 OSS 模型的小多数（分别为 51% 和 53%）。总体而言，我们发现绝大多数受访者更喜欢使用开源模型（47%），只有 19% 偏好专有模型；37% 表示他们没有偏好。

受访者正在构建的最常见的服务包括摘要工具（56%）、文本生成工具（55%）和聊天机器人（46%）。开放式回复表明，其中许多用例是面向内部的，例如基于组织内部文档训练的聊天机器人，用于回答员工问题。受访者对面向外部的 AI 功能提出了一些担忧，最值得注意的是由于可靠性（例如，我的问题中的微小变化是否会导致截然不同的结果？）和准确性（例如，结果是否值得信赖？）问题。一个贯穿这些回复的有趣主题是，在完全不采用 AI 工具（从而在生成式 AI 未来变得必要时失去潜在的竞争优势）的风险与使用未经测试的 AI 在高风险的面向客户的领域中可能造成的负面宣传或违反法规/法律的风险之间存在一种紧张关系。

我们发现证据表明 Go 已经用于 GenAI 领域，并且似乎有更多的需求。大约三分之一的正在构建 AI 驱动功能的受访者告诉我们，他们已经在使用 Go 来完成各种 GenAI 任务，包括原型设计新功能和将服务与 LLM 集成。对于我们认为 Go 非常适合的两个领域：ML/AI 系统的 数据管道（37%）和托管 ML/AI 模型的 API 端点（41%），这些比例略有上升。除了这些（可能的早期）采用者之外，我们发现大约四分之一的受访者*希望*将 Go 用于这些类型的用途，但目前受到了一些阻碍。在探讨受访者最初为何希望将 Go 用于这些任务之后，我们将很快回到这些障碍。

使用 Go 处理生成式 AI 系统的原因

为了帮助我们理解开发者希望从 Go 在其 AI/ML 服务中获得的益处，我们询问了开发者为何认为 Go 是该领域的良好选择。绝大多数受访者（61%）提到了 Go 的核心原则或特性，如简洁性、运行时安全、并发或单二进制部署。三分之一的受访者提到了他们对 Go 的熟悉程度，包括希望避免引入新语言（如果可能的话）。最常见的回复是各种 Python 的挑战（尤其是运行生产服务），占 14%。

“我认为该语言提供的健壮性、简洁性、性能和原生二进制文件使其成为 AI 工作负载的更强大选择。” — 大型组织中拥有最多一年经验的开源 Go 开发者

“我们希望保持整个组织的技术栈尽可能同质化，以便每个人都能更轻松地在所有领域进行开发。由于我们已经在用 Go 编写所有后端，因此我们有兴趣能够用 Go 编写 ML 模型部署，并避免在像 Python 这样的单独语言中重写部分栈以进行日志记录、监控等。” — 中型组织中拥有 5-7 年经验的专业 Go 开发者

“Go 更适合我们运行 API 服务器和后台任务在工作池上。Go 较低的资源使用量使我们能够在不增加资源消耗的情况下实现增长。而且我们发现 Go 项目随着时间的推移更容易维护，无论是代码更改还是更新依赖项。我们将模型作为用 Python 编写的独立服务运行，并用 Go 与它们进行交互。” — 大型组织中拥有 5-7 年经验的专业 Go 开发者

似乎在对 ML/AI 感兴趣的 Go 开发者中，普遍认为 1) Go 本身是该领域的优秀语言（出于上述原因），并且 2) 一旦组织已经投资于 Go，他们就倾向于避免引入新语言（这一点可以合理地推广到任何语言）。一些受访者还对 Python 的某些方面表示沮丧，例如类型安全、代码质量和部署挑战。

使用 Go 处理 GenAI 系统的挑战

受访者在当前阻止他们使用 Go 来处理 AI 驱动的服务方面基本达成一致：生态系统以 Python 为中心，他们最喜欢的库/框架都在 Python 中，入门文档假定熟悉 Python，而探索这些模型的数据科学家或研究人员已经熟悉 Python。

“Python 似乎拥有所有库。例如，PyTorch 被广泛用于运行模型。如果 Go 中有运行这些模型的框架，我们更愿意这样做。” — 大型组织中拥有 2-4 年经验的专业 Go 开发者

“Python 工具的成熟度和开箱即用性大大提高，从而大大降低了实施成本。” — 小型组织中拥有 2-4 年经验的专业 Go 开发者

“[Go 世界] 缺少许多 AI 库。如果我有一个 LLM PyTorch 模型，我甚至无法对其进行服务（或者我不知道如何做）。使用 Python，这基本上只需要几行代码。” — 小型组织中拥有最多一年经验的专业 Go 开发者

这些发现与我们上面关于 Go 开发者认为 Go *应该*成为构建生产就绪 AI 服务的绝佳语言的观察结果非常吻合：只有 3% 的受访者表示 Go 本身的某些东西阻碍了他们的前进道路，只有 2% 的受访者提到了与 Python 的特定互操作性挑战。换句话说，开发者面临的大多数障碍都可以在模块和文档生态系统中解决，而无需进行核心语言或运行时更改。

我们还询问了调查参与者他们是否已经在与 Python 合作进行 GenAI，如果他们在，他们是否更愿意使用 Go。表示更愿意使用 Go 而不是 Python 的受访者还收到了一份后续问题，询问什么将使他们能够将 Go 用于 GenAI 系统。

绝大多数受访者（62%）报告说他们已经在使用 Python 集成生成式 AI 模型；在这部分人中，57% 的人宁愿使用 Go。鉴于我们的调查受众都是 Go 开发者，我们应该预期这将在当前每个生态系统的状态下，大致构成对从 Python 转向 Go 进行 GenAI 任务感兴趣的总体开发者的比例上限。

在那些已经使用 Python 但更愿意使用 Go 的受访者中，绝大多数（92%）表示拥有 Python 库的 Go 等价物将使他们能够将 Go 集成到 GenAI 系统中。然而，我们应该谨慎解读这个结果；开放式文本回复和对从事 GenAI 服务的开发者的单独访谈描述了一个以 Python 为中心的 GenAI 生态系统；Go 不仅在与 Python 生态系统相比缺乏许多库，而且 Go 库的投资水平较低，文档和示例主要以 Python 呈现，而该领域的专家网络已经习惯了 Python。使用 Python 进行实验和构建概念验证几乎肯定会继续下去，而 Python 库（例如 pandas）的 Go 变体缺失只是开发者在尝试从 Python 迁移到 Go 时会遇到的第一个障碍。库和 SDK 是必需的，但本身不太可能足以构建一个强大的 Go 生态系统来支持生产 ML/AI 应用。

此外，对构建 AI 驱动服务的 Go 开发者的访谈表明，*从 Go 调用* API 并不是一个主要问题，特别是对于托管模型，如 GPT-4 或 Gemini。在 Go 中构建、评估和托管自定义模型被认为具有挑战性（主要是由于缺乏支持 Python 中此功能的相关框架和库），但访谈参与者区分了爱好用途（例如，在家玩弄自定义模型）和业务用途。爱好用途在上述所有原因下都由 Python 主导，但业务用途则更侧重于可靠性、准确性和性能，而调用托管模型。在这一点上，Go 可以在*不*构建大型 ML/AI/数据科学库生态系统的情况下大放异彩，尽管我们预计开发者仍将从文档、最佳实践指南和示例中受益。

由于 GenAI 领域非常新颖，最佳实践仍在确定和测试中。初步的开发者访谈表明，他们的目标之一是为生成式 AI 成为竞争优势的未来做好准备；通过在这一领域进行一些投资，他们希望减轻未来的风险。他们还在努力了解哪些 GenAI 系统可能有帮助，以及投资回报（如果有的话）可能是什么样的。由于这些未知因素，我们的早期数据显示，组织（尤其是在科技行业之外）可能不愿意在此做出长期承诺，而是将采取精益或零散的方法，直到出现具有明确效益的可靠用例，或者他们的行业同行开始在该领域进行大量公开投资。

学习挑战

为了改善学习 Go 的体验，我们想听取有 Go 经验不足的开发者的意见，以及那些可能已经掌握基础知识的人，听听他们认为实现学习目标的最大挑战是什么。我们也想听听那些可能主要专注于帮助他人开始使用 Go 而非他们自己学习目标的开发者，因为他们可能对他们看到的入门开发者的常见挑战有一些见解。

只有 3% 的受访者表示他们目前正在学习 Go 的基础知识。这并不意外，因为我们的大多数调查受访者至少有一年的 Go 经验。与此同时，40% 的受访者表示他们已经学会了基础知识，但想学习更高级的主题，另有 40% 的人表示他们帮助其他开发者学习 Go。只有 15% 的人表示他们没有任何与 Go 相关的学习目标。

当我们查看更细粒度的 Go 经验时间段时，我们发现不到三个月使用 Go 的人中有 30% 表示他们正在学习 Go 的基础知识，而其中约三分之二的人表示他们已经学会了基础知识。这有力地证明了一个人可以在短时间内学会 Go 的基础知识，但这也意味着我们从这个学习旅程开始阶段的群体中获得的反馈不多。

为了确定社区可能最需要哪种学习材料，我们询问了受访者在软件开发相关主题方面偏好的学习内容类型。他们可以选择多个选项，因此这里的数字超过了 100%。87% 的受访者表示他们偏好书面内容，这是迄今为止最受欢迎的格式。52% 的人表示偏好视频内容，尤其是这种格式更受经验较少开发者的青睐。这可能表明对视频格式学习内容日益增长的需求。然而，经验较少的群体对书面内容的偏好程度并不低于其他群体。同时提供书面和视频格式已被证明可以提高学习成果，并且有助于不同学习偏好和能力的开发者，这可以提高 Go 社区中学习内容的可用性。

我们询问了那些表示有 Go 学习目标的学生，他们实现目标的最大挑战是什么。这个问题故意留得足够宽泛，这样刚入门的人或已经掌握基础知识的人都可以回答。我们也想给受访者一个机会来告诉我们他们面临的各种挑战，而不仅仅是那些他们觉得困难的话题。

压倒性多数提到最多的挑战是缺乏时间或其他个人限制，例如专注度或学习动力（44%）。虽然我们不能给受访者更多时间，但在我们制作学习材料或引入生态系统更改时，我们应该注意用户可能面临严重的时间限制。教育工作者也有机会制作可以分小块消化或以规律的节奏的学习资源，以保持学习者的积极性。

除了时间之外，排在前列的挑战是学习 Go 特有的新概念、惯用法或最佳实践（11%）。特别是，从 Python 或 JavaScript 适应静态类型编译语言以及学习如何组织 Go 代码可能特别具有挑战性。受访者还要求提供更多示例（6%），包括文档和实际应用程序，以供学习。来自更大开发者社区的开发者期望能够找到更多的现有解决方案和示例。

“从 Python 这样的语言转到静态类型编译语言很有挑战性，但 Go 本身并不难。我喜欢通过快速反馈来学习，所以 Python 的 REPL 非常有用。所以现在我需要专注于真正阅读文档和示例才能学会。Go 的一些文档相当稀疏，需要更多示例。” — 有不到 3 年 Go 经验的受访者。

“我的主要挑战是缺乏企业级应用程序的示例项目。如何组织一个大型 Go 项目是我希望获得更多示例作为参考的。我想重构我目前正在处理的项目，使其采用更模块化/干净的架构风格，由于缺乏示例/更具指导性的“文件夹/包”参考，我在 Go 中发现这很困难。” — 有 1-2 年 Go 经验的受访者。

“它比我习惯的生态系统要小，所以在网上搜索的特定问题的结果不多。现有的资源非常有帮助，我通常最终都能解决问题，只是需要更长的时间。” — 有不到 3 个月 Go 经验的受访者。

对于那些主要学习目标是帮助他人开始使用 Go 的受访者，我们询问了什么可以使开发者更容易开始使用 Go。我们收到了各种各样的回复，包括文档建议、关于困难主题的评论（例如，使用指针或并发），以及要求添加其他语言中更熟悉的特性。对于占回复量不到 2% 的类别，我们将其归为“其他”回复。有趣的是，没有人提到“更多时间”。我们认为这是因为当没有立即学习 Go 新东西的必要性时，缺乏时间或动力是最常见的挑战。对于那些帮助他人开始使用 Go 的人来说，可能存在商业原因，更容易确定优先级，因此“缺乏时间”不是一个大挑战。

与之前的研究结果一致，那些帮助他人开始使用 Go 的人中有 16% 告诉我们，新的 Go 开发者将受益于更多的实际示例或项目式练习来学习。他们还看到了帮助来自其他语言生态系统的开发者的需求，通过比较他们。 之前的研究告诉我们，一种编程语言的经验会干扰学习新语言，特别是当新的概念和工具与开发人员习惯的不同时。现有的资源旨在解决这个问题（只需搜索“Golang for [language] developers”即可找到示例），但新 Go 开发者可能难以搜索他们尚未掌握词汇的概念，或者这些类型的资源可能无法充分解决特定任务。未来，我们希望更多地了解如何以及何时进行语言比较，以促进新概念的学习。

这个群体报告的一个相关需求是，需要更多关于 Go 哲学和最佳实践的解释。学习不仅*是什么*使 Go 与众不同，而且*为什么*会帮助新的 Go 开发者理解新概念或与他们之前的经验不同的任务方式。

人口统计

我们在每次调查周期中都会提出相似的人口统计学问题，以便了解一年一年的结果的可比性。例如，如果在一项调查周期中，大多数受访者报告的 Go 经验不到一年，那么与以前的周期相比，任何其他差异很可能源于这个主要的人口结构变化。我们也使用这些问题来提供群体之间的比较，例如根据受访者使用 Go 的时间长短来衡量满意度。

今年，我们对 Go 经验的提问方式进行了一些微小的改动，以匹配 JetBrains 开发者调查。这使我们能够比较我们的调查人群，并促进了数据分析。

我们看到，根据开发者发现我们调查的方式，经验水平上存在一些差异。在 VS Code 中收到调查通知的人群倾向于 Go 经验较少；我们怀疑这反映了 VS Code 在新 Go 开发者中的受欢迎程度，他们可能还没有准备好在学习过程中为 IDE 许可证付费。就 Go 经验年限而言，从 GoLand 随机选择的受访者与通过 Go Blog 找到调查的自选人群更相似。在这些样本之间看到一致性，使我们能够更有信心地将调查结果推广到整个 Go 社区。

除了 Go 经验年限外，今年我们还衡量了专业编码经验年限。我们惊讶地发现，26% 的受访者拥有 16 年或更长的专业编码经验。相比之下，JetBrains 开发者调查受众 在 2023 年的大多数受访者拥有 3-5 年的专业经验。拥有更经验丰富的受众可能会影响响应的差异。例如，我们看到了受访者在他们偏好的学习内容类型方面存在显著差异。

当我们查看不同的样本时，自选群体的经验甚至比随机选取的群体更丰富，29% 的人拥有 16 年或更多的专业经验。这表明我们的自选群体总体上比我们随机选取的群体更有经验，并且可以解释我们在这个群体中看到的一些差异。

在本周期中，我们还引入了一个关于就业状况的人口统计学问题，以帮助我们与 JetBrains 的开发者调查 进行比较。我们发现 81% 的受访者是全职就业的，这显著高于 JetBrains 调查中的 63%。我们发现我们人口中的学生比例也显著较低（4%），而 JetBrains 调查中为 15%。当我们查看我们的个体样本时，我们看到 VS Code 受访者之间存在微小但显著的差异，他们完全就业的可能性略低，而成为学生的可能性略高。考虑到 VS Code 是免费的，这是有道理的。

与往年类似，Go 最常见的用例是 API/RPC 服务（74%）和命令行工具（63%）。我们听说 Go 内置的 HTTP 服务器和并发原语、跨编译的便捷性以及单二进制部署使其成为此类应用程序的良好选择。

我们还根据受访者对 Go 的经验水平和组织规模进行了差异分析。经验更丰富的 Go 开发者报告说他们使用 Go 构建了更多样化的应用程序。这一趋势在所有类型的应用或服务类别中都是一致的。我们没有发现受访者根据其组织规模在构建内容上有任何显著差异。

企业信息

我们听取了来自各种不同组织的受访者的意见。约 27% 的人受雇于拥有 1000 名或更多员工的大型组织，25% 的人来自拥有 100-1000 名员工的中型组织，43% 的人受雇于拥有不到 100 名员工的小型组织。与往年一样，人们工作最多的行业是技术（48%），其次是金融服务（13%）。

这在统计学上与过去几次 Go 开发者调查没有变化——我们继续以一贯的比例听到来自不同国家、不同规模和不同行业组织的人的反馈。

方法论

在 2021 年之前，我们主要通过 Go Blog 发布调查。该调查在 Twitter、Reddit 或 Hacker News 等各种社交渠道上被转载。2021 年，我们通过使用 VS Code Go 插件随机选择用户，让他们看到一个提示，询问他们是否愿意参加调查，从而引入了一种新的招募受访者的方式。这创建了一个随机样本，我们用它来比较来自传统渠道的自选受访者，并帮助识别 选择性偏差 的潜在影响。对于本周期，我们在 JetBrains 的朋友们慷慨地为我们提供了一个额外的随机样本，方法是向 GoLand 用户的一个随机子集发出调查邀请！

64% 的调查受访者是“自愿”参加调查的，这意味着他们是在 Go 博客或其他社交 Go 频道上找到的。不关注这些频道的人不太可能从它们那里了解调查，在某些情况下，他们的回答与密切关注他们的人不同。例如，他们可能是 Go 社区的新成员，还不知道 Go 博客。大约 36% 的受访者是随机抽样的，这意味着他们看到了 VS Code（25%）或 GoLand（11%）中的提示后才回复了调查。在 2024 年 1 月 23 日至 2 月 13 日期间，用户看到此提示的几率约为 10%。通过检查随机抽样群体与自选回复以及他们之间的差异，我们可以更有信心地将调查结果推广到更广泛的 Go 开发者社区。

如何解读这些结果

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

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

结语

以上就是我们半年度 Go 开发者调查的全部内容。非常感谢所有分享他们对 Go 看法的人，以及所有为完成这次调查做出贡献的人！这对我们意义重大，并且真正帮助我们改进 Go。

今年我们也很高兴地宣布即将发布本次调查的数据集。我们预计在 4 月底分享这些匿名数据，让任何人都可以根据需要切分和整理调查回复，以回答他们自己关于 Go 生态系统的问题。

更新于 2024-05-03：我们很遗憾地通知，数据集的发布将推迟。我们仍在努力实现这一目标，但预计要到 2024 年下半年才能分享。

— Alice 和 Todd（代表 Google Go 团队）