Go 博客

2024 年上半年 Go 开发者调查结果

Alice Merrick 和 Todd Kulesza
2024 年 4 月 9 日

背景

本文分享了我们最近一次 Go 开发者调查的结果，该调查于 2024 年 1 月和 2 月进行。除了了解使用 Go 和 Go 工具方面的情绪和挑战外，本次调查的主要关注领域是开发者如何开始将 Go（或其他语言）用于人工智能相关的用例，以及学习 Go 或希望扩展其 Go 技能的开发者面临的特殊挑战。

我们通过 Go 博客以及 VS Code Go 插件中的随机提示招募了参与者。今年，在 JetBrains 的帮助下，我们还在 GoLand IDE 中包含了随机调查提示，这使我们能够招募到更具代表性的 Go 开发者样本。我们总共收到了 6,224 份回复！衷心感谢所有为此做出贡献的人。

亮点

• 开发者满意度保持较高水平，93% 的受访者表示对过去一年使用 Go 感到满意。
• 大多数受访者 (80%) 表示，他们相信 Go 团队在维护和发展该语言时会“做对开发者最有利的事情”。
• 在构建人工智能驱动的应用和服务的受访者中，大家普遍认为 Go 是在生产环境中运行这些类型应用的强大平台。例如，大多数从事人工智能驱动应用工作的受访者已经在用 Go 或希望将其人工智能相关工作负载迁移到 Go，并且开发者遇到的最严峻挑战与库和文档生态系统相关，而不是核心语言和运行时。尽管如此，当前最常见的入门文档路径都以 Python 为中心，导致许多组织在转向更适合生产的语言之前，先用 Python 开始人工智能相关工作。
• 受访者正在构建的最常见人工智能驱动服务包括摘要工具、文本生成工具和聊天机器人。回复表明，其中许多用例都是内部面向的，例如基于组织内部文档训练的聊天机器人，旨在回答员工问题。我们推测，组织有意从内部用例开始，以发展内部关于 LLM 的专业知识，同时避免人工智能代理行为异常时可能引起的公开尴尬。
• 缺乏时间或机会是受访者实现其 Go 相关学习目标时最常提到的挑战，这表明如果没有明确的目标或业务需求，语言学习很难被优先考虑。其次最常见的挑战是，从其他语言生态系统转来时，学习 Go 特有的新最佳实践、概念和惯用法。

目录

• 开发者满意度
• 开发者环境
• 资源和性能优先级
• 了解 Go 在人工智能方面的用例
• 学习挑战
• 人口统计信息
• 企业统计信息
• 调查方法
• 结束语

开发者满意度

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

信任

今年，我们引入了一个衡量开发者信任度的新指标。这是一个实验性问题，随着我们对受访者如何解读它的了解加深，措辞可能会随时间改变。由于这是我们第一次问这个问题，我们没有往年的数据来为结果提供背景。我们发现，80% 的受访者比较同意或非常同意他们信任 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 中的 enums、option types 或 sum types。通常我们没有获得关于这些请求的太多背景信息，但我们怀疑这与近期关于 enums 的一些提案和社区讨论、越来越多来自其他常见这些功能的语言生态系统的人，或者期待这些功能能减少编写模板代码的期望有关。一个与类型系统相关的更全面的评论解释如下：

“这些不是大挑战，而更多是我在语言中怀念的便利性。总有办法绕过它们，但如果不用考虑这些会很好。”

Sum types/closed enums 可以模拟实现，但这很麻烦。当与那些对响应中特定元素/字段只有有限集合值，且超出范围的值即为错误的 API 交互时，这是一个非常方便的功能。它有助于在入口点进行验证和捕获问题，并且通常可以直接从 JSON Schema、OpenAPI 或者像 XML Schema Definitions 这样的 API 规范生成。

我一点也不介意错误检查的冗长性，但是指针的 nil 检查变得非常繁琐，尤其是在需要深入到层层嵌套的包含指针字段的结构体时。如果能有某种 Optional/Result 类型，或者能够遍历指针链并简单地返回 nil 而不是触发运行时 panic，那就太好了。”

开发者环境

与往年一样，大多数受访者在 Linux (61%) 和 macOS (58%) 系统上使用 Go 进行开发。虽然这些数字年复一年变化不大，但我们在自我选择的样本中确实看到了一些有趣的差异。来自 JetBrains 和 VS Code 的随机抽样组比自我选择组 (19%) 更倾向于在 Windows 上开发（分别为 31% 和 33%）。我们不确定为什么自我选择组如此不同，但我们推测，由于他们很可能是通过阅读 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 开发者正在使用哪些云平台以及他们对三个最受欢迎的平台（Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud）的满意度如何。这一部分只对表示主要工作使用 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 在人工智能方面的用例

我们的上次调查询问了 Go 开发者关于他们早期使用生成式 AI 系统的情况。在本轮调查中，我们深入了一点，问了几个与 AI 相关的问题，以了解受访者如何构建人工智能驱动（更具体地说，是 LLM 驱动）的服务。我们发现，一半的受访者 (50%) 所在组织正在构建或探索人工智能驱动的服务。其中，超过一半 (56%) 的人表示他们参与了为其组织服务添加 AI 功能的工作。我们其余与 AI 相关的问题仅向这一部分受访者展示。

请谨慎地将这些参与者的回复泛化到所有 Go 开发者群体。由于只有大约 ¼ 的受访者正在从事人工智能驱动的服务工作，我们建议使用这些数据来了解这一领域的早期采用者，并注意早期采用者往往与最终会采用技术的大多数人有所不同。例如，我们预计这部分受众正在尝试比一两年后可能更多的模型和 SDK，并且在将这些服务集成到现有代码库时会遇到更多挑战。

在专业从事生成式 AI (GenAI) 系统工作的 Go 开发者群体中，绝大多数 (81%) 报告使用了 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列开源模型也获得了较高的采用率，大多数受访者 (53%) 至少使用了 Llama、Mistral 或其他一个 OSS 模型。我们看到一些早期证据表明，大型组织（员工人数超过 1,000 人）使用 OpenAI 模型的可能性略低（74% 对 83%），而使用其他专有模型的可能性略高（22% 对 11%）。然而，我们没有看到基于组织规模在采用 OSS 模型方面有任何差异的证据——小型公司和大型企业都有小部分多数人采用 OSS 模型（分别为 51% 和 53%）。总的来说，我们发现多数受访者偏好使用开源模型 (47%)，只有 19% 偏好专有模型；37% 表示没有偏好。

受访者正在构建的最常见服务类型包括摘要工具 (56%)、文本生成工具 (55%) 和聊天机器人 (46%)。开放文本回复表明，其中许多用例是内部面向的，例如基于组织内部文档训练的聊天机器人，旨在回答员工问题。受访者对外部面向的 AI 功能提出了一些担忧，最主要的是可靠性（例如，我的问题略微改变是否会导致结果差异很大？）和准确性（例如，结果是否可信？）问题。贯穿这些回复的一个有趣主题是，不采用 AI 工具的风险（以及因此可能在未来生成式 AI 变得必要时失去潜在竞争优势）与在高重要性客户面向领域使用未经测试的 AI 带来的负面宣传或违反法规/法律的风险之间的紧张感。

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

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

为了帮助我们了解开发者希望从在其 AI/ML 服务中使用 Go 中获得哪些益处，我们询问了开发者为什么他们觉得 Go 在这个领域是一个好选择。绝大多数 (61%) 受访者提到了 Go 的一个或多个核心原则或特性，例如简洁性、运行时安全性、并发性或单一二进制文件部署。三分之一的受访者提到了对 Go 已有的熟悉度，包括如果可能的话，希望避免引入新语言。最常见的回复还包括在使用 Python 时遇到的各种挑战 (14%)，特别是在运行生产服务方面。

“我认为 Go 语言提供的健壮性、简洁性、性能和原生二进制文件使其成为 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 用于人工智能驱动的服务的原因上基本一致：生态系统以 Python 为中心，他们喜欢的库/框架都在 Python 中，入门文档假定熟悉 Python，并且探索这些模型的数据科学家或研究人员已经熟悉 Python。

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

“Python 工具要成熟得多，开箱即用，这使得实施成本显著降低。” — 某小型组织中具有 2 – 4 年 Go 经验的专业开发者

“[The] Go 世界缺少很多人工智能库。如果我有一个 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%) 表示，Go 语言中存在 Python 库的等效库将使他们能够将 Go 与 GenAI 系统集成。然而，解读这一结果时我们应保持谨慎；开放文本回复以及与从事 GenAI 服务开发者的独立访谈描述了一个以 Python 为中心的 GenAI 生态系统；不仅 Go 相比 Python 生态系统缺少许多库，而且对 Go 库投入的感知水平较低，文档和示例主要以 Python 编写，并且在该领域工作的专家群体已经熟悉 Python。在 Python 中进行实验和构建概念验证几乎肯定会继续，而 Go 缺少 Python 库的变体（例如 pandas）只是开发者在尝试从 Python 移植到 Go 时会遇到的第一个障碍。库和 SDK 是必要的，但仅靠它们本身不太可能足以构建一个强大的 Go 生态系统用于生产 ML/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 经验更细分的时间段时，我们发现使用 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 的人来说，可能有商业原因促使他们这样做，从而更容易确定优先级，因此“缺乏时间”不是一个主要的挑战。

与之前的结果一致，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 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 开发者表示他们使用 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 blog 或其他 Go 社交渠道上找到了调查。不关注这些渠道的人不太可能从这些渠道得知调查信息，并且在某些情况下，他们的回复与密切关注这些渠道的人不同。例如，他们可能是 Go 社区的新成员，还不了解 Go blog。约 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 团队）