Go 开发者调查 2024 年结果(AI相关)-CSDN博客

背景

这篇文章分享了我们在 2024 年 1 月和 2 月进行的最新 Go 开发者调查的结果。除了捕捉有关使用 Go 和 Go 工具的观点和挑战之外，我们本次调查的主要关注领域是开发者如何开始使用 Go（或其他语言）的 AI 相关用例，以及那些正在学习 Go 或希望扩展 Go 技能集的人面临的特殊挑战。

我们从 Go 博客以及 VS Code Go 插件中的随机提示招募参与者。今年，在 JetBrains 的帮助下，我们还在 GoLand IDE 中加入了随机调查提示，使我们能够招募更具代表性的 Go 开发人员样本。我们总共收到 6,224 条回复！非常感谢所有为实现这一目标做出贡献的人们。

强调

开发者情绪依然高涨，93% 的受访者对过去一年的 Go 表示满意。
大多数受访者 (80%) 表示，他们相信 Go 团队在维护和发展该语言时会为像他们这样的开发人员“做最好的事情”。
在构建人工智能驱动的应用程序和服务的调查受访者中，有一个共同的感觉，即 Go 是在生产中运行此类应用程序的强大平台。例如，大多数使用人工智能驱动的应用程序的受访者已经使用 Go 或希望迁移到 Go 来处理人工智能驱动的工作负载，而开发人员遇到的最严峻的挑战与库和文档生态系统有关，而不是与核心语言有关和运行时。也就是说，目前最常见的入门路径是以 Python 为中心的，这导致许多组织在转向更适合生产的语言之前先使用 Python 开始人工智能驱动的工作。
受访者正在构建的最常见的人工智能服务包括摘要工具、文本生成工具和聊天机器人。回应表明，其中许多用例都是面向内部的，例如根据组织的内部文档进行训练并旨在回答员工问题的聊天机器人。我们假设组织有意从内部用例开始，通过 LLMs 开发内部专业知识，同时避免人工智能驱动的代理出现意外行为时潜在的公众尴尬。
缺乏时间或机会是受访者在实现 Go 相关学习目标时最常提到的挑战，这表明如果没有特定的目标或业务案例，很难确定语言学习的优先顺序。下一个最常见的挑战是学习来自其他语言生态系统的 Go 特有的新最佳实践、概念和习惯用法。

内容

开发商情绪

调查中的总体满意度仍然很高，93% 的受访者表示他们去年对 Go 感到有些或非常满意。考虑到我们的受众是那些自愿参加我们调查的人，这并不奇怪。但即使在从 VS Code 和 GoLand 中随机抽样的人中，我们仍然看到类似的满意度 (92%)。尽管不同调查的确切百分比略有波动，但我们没有发现与 2023 年下半年的满意度有任何统计上的显着差异，当时的满意度为 90%。

信任

今年，我们引入了衡量开发人员信任度的新指标。这是一个实验性问题，随着我们更多地了解受访者如何解释它，其措辞可能会随着时间的推移而改变。因为这是我们第一次提出这个问题，所以我们没有前几年的资料来为我们的结果提供背景信息。我们发现 80% 的受访者在某种程度上或强烈同意他们相信 Go 团队会为像他们这样的用户做最好的事情。拥有 5 年或以上 Go 经验的受访者 (83%) 比那些经验不足 2 年的受访者 (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 架构、OpenAPI 或天堂禁止的 XML 架构定义）生成。

我根本不介意错误检查的冗长性，但是指针的 nil 检查会变得乏味，尤其是当[我]需要钻取深度嵌套的指针字段结构时。某种形式的可选/结果类型或追踪指针链并简单地返回 nil 而不是触发运行时恐慌的能力将受到赞赏。”

开发者环境

与往年一样，大多数调查受访者在 Linux (61%) 和 macOS (58%) 系统上使用 Go 进行开发。尽管这些数字每年都没有太大变化，但我们确实在我们自己选择的样本中发现了一些有趣的差异。从 JetBrains 和 VS Code 中随机抽取的组（分别为 31% 和 33%）比自行选择的组（19%）更有可能在 Windows 上进行开发。我们并不确切知道为什么自选群体如此不同，但我们假设，因为他们很可能是通过阅读 Go 博客而遇到这项调查的，所以这些受访者是社区中最活跃、经验最丰富的开发者。他们的操作系统偏好可能反映了通常在 Linux 和 macOS 上开发的核心开发团队的历史优先事项。值得庆幸的是，我们有来自 JetBrains 和 VS Code 的随机样本，可以提供更具代表性的开发人员偏好视图。

作为对使用 WSL 进行开发的 17% 受访者的跟踪调查，我们询问他们正在使用哪个版本。在 WSL 上进行开发的受访者中有 93% 使用的是版本 2，因此 Microsoft 的 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和谷歌云。此部分仅向表示使用 Go 作为主要工作的受访者展示，约占受访者总数的 76%。98% 看到这个问题的人都在使用与云服务集成的 Go 软件。超过一半的受访者使用 AWS (52%)，而 27% 的受访者使用 GCP 进行 Go 开发和部署。对于 AWS 和 Google Cloud，我们认为小型或大型公司使用任一提供商的可能性没有任何差异。Microsoft Azure 是唯一一家比小型企业更有可能在大型组织（员工人数超过 1,000 名的公司）中使用的云提供商。我们没有发现任何其他云提供商根据组织规模的使用情况存在任何显着差异。

将 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 的体验。

我们首先询问了一个关于受访者使用 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 开发者有关生成式 AI 系统的早期经验。为了更深入地了解这个周期，我们提出了几个与人工智能相关的问题，以了解受访者如何构建人工智能驱动的（更具体地说，LLM驱动的）服务。我们发现，一半的调查受访者 (50%) 在正在构建或探索人工智能服务的组织中工作。其中，超过一半 (56%) 表示他们参与了在其组织的服务中添加人工智能功能的工作。我们剩下的与人工智能相关的问题仅向这部分受访者展示。

请谨慎地将这些参与者的反应推广到 Go 开发者的总体群体。由于只有约 1/4 的受访者正在使用人工智能服务，因此我们建议使用这些数据来了解该领域的早期采用者，但需要注意的是，早期采用者往往与大多数最终采用人工智能的人有所不同一项技术。例如，我们预计这些受众将尝试比现在一两年更多的模型和 SDK，并且会遇到更多与将这些服务集成到现有代码库相关的挑战。

在专业使用生成式 AI (GenAI) 系统的 Go 开发人员中，绝大多数 (81%) 表示使用 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列开源模型也得到了很高的采用，大多数受访者 (53%) 至少使用 Llama、Mistral 或其他 OSS 模型中的一个。我们看到一些早期证据表明，较大的组织（1,000 名以上员工）使用 OpenAI 模型的可能性较小（74% vs. 83%），而使用其他专有模型的可能性较高（22% vs. 11%）。然而，我们没有看到任何证据表明 OSS 模型的采用因组织规模而异，无论是小型公司还是大型企业，都显示只有少数人采用 OSS 模型（分别为 51% 和 53%）。总体而言，我们发现许多受访者更喜欢使用开源模型 (47%)，只有 19% 的受访者更喜欢专有模型；37% 的人表示他们没有偏好。

受访者构建的最常见服务类型包括摘要工具 (56%)、文本生成工具 (55%) 和聊天机器人 (46%)。开放文本回复表明，许多用例都是面向内部的，例如根据组织内部文档进行训练并旨在回答员工问题的聊天机器人。受访者对面向外部的人工智能功能提出了一些担忧，最明显的是由于可靠性（例如，我的问题的微小变化是否会导致截然不同的结果？）和准确性（例如，结果是否可信？）问题。这些回应中贯穿着一个有趣的主题，即根本不采用人工智能工具的风险（如果将来需要生成人工智能，就会失去潜在的竞争优势）与负面宣传或违反法规的风险之间的紧张感/法律在面向客户的高关键领域使用未经测试的人工智能。

我们发现证据表明 Go 已经在 GenAI 领域得到使用，而且似乎有更多的需求。大约 ⅓ 正在构建人工智能功能的受访者告诉我们，他们已经在使用 Go 来执行各种 GenAI 任务，包括设计新功能原型以及与 LLMs 集成服务。对于我们认为 Go 特别适合的工具的两个领域，这些比例略有上升：ML/AI 系统的数据管道 (37%) 和 ML/AI 模型的托管 API 端点 (41%)。除了这些（可能是早期的）采用者之外，我们发现大约 1/4 的受访者希望将 Go 用于这些类型的用途，但目前受到某些因素的阻碍。在探讨了为什么受访者首先想要使用 Go 来完成这些任务之后，我们很快就会回到这些阻碍因素。

将 Go 与生成式 AI 系统结合使用的原因

为了帮助我们了解开发人员希望在 AI/ML 服务中使用 Go 获得什么好处，我们询问开发人员为什么他们认为 Go 是该领域的不错选择。绝大多数 (61%) 的受访者提到了 Go 的一项或多项核心原则或功能，例如简单性、运行时安全性、并发性或单一二进制部署。三分之一的受访者提到了对 Go 的现有熟悉程度，包括希望避免引入新语言（如果可以避免的话）。最常见的回答是 Python 的各种挑战（特别是运行生产服务），占 14%。

“我认为该语言提供的稳健性、简单性、性能和本机二进制文件使其成为人工智能工作负载的更强有力的选择。” — 大型组织的开源 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 年经验

“Go世界缺少许多人工智能库。如果我有一个 LLM PyTorch 模型，我什至无法提供它（或者我不知道如何做到这一点）。对于 Python 来说，基本上就是几行代码。” — 小型组织的专业 Go 开发人员，拥有最多 1 年的经验

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

我们还询问了调查参与者是否已经在使用 Python 来实现 GenAI，如果是，他们是否更愿意使用 Go。表示更愿意使用 Go 而不是 Python 的受访者还收到了有关如何使他们能够在 GenAI 系统中使用 Go 的后续信息。

绝大多数 (62%) 的受访者表示已经使用 Python 与生成式 AI 模型集成；在这个群体中，57% 的人宁愿使用 Go。鉴于我们的调查受众都是 Go 开发人员，考虑到当今每个生态系统的状态，我们应该预计这将是有兴趣从 Python 迁移到 Go 来执行 GenAI 任务的总体开发人员比例的近似上限。

在已经使用 Python 但更愿意使用 Go 的受访者中，绝大多数 (92%) 表示，Python 库的 Go 等效项的可用性将使他们能够将 Go 与 GenAI 系统集成。然而，我们在解释这一结果时应该谨慎；开放文本回复以及对 GenAI 服务开发人员的一组单独的上下文访谈描述了围绕 GenAI 的以 Python 为中心的生态系统；与 Python 生态系统相比，Go 不仅缺乏许多库，而且人们对 Go 库的投资感知水平较低，文档和示例主要采用 Python，而且该领域的专家网络已经很熟悉Python。在 Python 中进行实验和构建概念验证几乎肯定会继续下去，而缺乏 Python 库的 Go 变体（例如 pandas）只是开发人员在尝试从 Python 移植到 Go 时遇到的第一个障碍。库和 SDK 是必要的，但它们本身不足以为生产 ML/AI 应用程序构建强大的 Go 生态系统。

此外，对构建人工智能服务的 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 体验时间段时，我们发现使用 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 中很难做到这一点，因为缺乏示例/更加固执己见的“文件夹/包”参考。” — 受访者拥有 1 到 2 年的 Go 经验。

“这是一个比我习惯的更小的生态系统，因此在线搜索不会针对特定问题产生那么多结果。现有的资源非常有帮助，我通常能够最终解决问题，只是需要更长的时间。”——拥有 Go 经验不到 3 个月的受访者。

对于主要学习目标是帮助其他人开始使用 Go 的受访者，我们询问什么可以让开发人员更轻松地开始使用 Go。我们收到了广泛的回复，包括文档建议、对困难主题的评论（例如，使用指针或并发），以及添加来自其他语言的更熟悉的功能的请求。对于占回复总数不到 2% 的类别，我们将其归入“其他”回复中。有趣的是，没有人提到“更多时间”。我们认为这是因为当不需要立即学习与 Go 相关的新知识时，缺乏时间或动力通常是一个挑战。对于那些帮助其他人开始使用 Go 的人来说，这样做可能有商业原因，这样更容易确定优先级，因此“缺乏时间”并不是一个太大的挑战。

与之前的结果一致，在帮助他人开始使用 Go 的人中，有 16% 的人告诉我们，新的 Go 开发人员会从更现实的示例或基于项目的练习中受益。他们还看到需要通过比较来帮助来自其他语言生态系统的开发人员。之前的研究告诉我们，使用一种编程语言的经验可能会干扰学习新语言，尤其是当新概念和工具与开发人员习惯的不同时。有旨在解决此问题的现有资源（例如，尝试搜索“Golang for [语言]开发人员”），但对于新的 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% 的人在拥有 1,000 名或以上员工的大型组织工作，25% 来自拥有 100-1,000 名员工的中型组织，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。今年，我们还很高兴地宣布即将发布该调查数据集。我们预计在 4 月底之前分享这些匿名数据，允许任何人根据需要对调查回复进行切片和切块，以回答他们自己关于 Go 生态系统的问题。