Go 博客

Go 开发者调查 2023 下半年结果

Todd Kulesza
2023 年 12 月 5 日

背景

2023 年 8 月，Google 的 Go 团队对 Go 开发者进行了半年一次的调查。我们通过 Go 博客上的公开帖子和 VS Code 中的随机提示招募参与者，共收集到 4,005 份回复。调查问题主要围绕以下几个主题：关于使用 Go 进行开发的总体感受和反馈、与 Go 一起使用的技术栈、开发者如何启动新的 Go 项目、近期使用工具链错误消息的体验，以及了解开发者对 ML/AI 的兴趣。

感谢所有参与本次调查的人！本报告分享了我们从您的反馈中了解到的内容。

概要

1. Go 开发者表示，他们对能提高他们所编写代码的质量、可靠性和性能的 AI/ML 工具更感兴趣，而不是为他们编写代码的工具。一个随时待命、从不忙碌的专家“审阅者”可能是 AI 开发者协助中最有用的形式之一。
2. 关于改进工具链警告和错误的最高呼声是使消息更易于理解和更具操作性；所有经验水平的开发者都认同这一看法，但在新接触 Go 的开发者中尤为强烈。
3. 我们对项目模板 (gonew) 的实验似乎解决了 Go 开发者（尤其是新接触 Go 的开发者）的关键问题，并且其方式与他们现有的启动新项目的工作流程相符。基于这些发现，我们相信 gonew 可以显著降低新 Go 开发者的入门门槛，并促进 Go 在组织中的采用。
4. 四分之三的受访者使用同时使用云服务的 Go 软件；这证明开发者将 Go 视为一种用于现代云原生开发的语言。
5. 开发者对 Go 的总体感受仍然非常积极，90% 的受访者表示他们在过去一年中使用 Go 工作时感到满意。

目录

• 开发者感受
• 开发者环境
• 技术栈
• 开发者如何启动新的 Go 项目
• 开发者对错误处理的目标
• 了解 ML/AI 使用场景
• 工具链错误消息
• 微服务
• 模块编写和维护
• 人口统计学信息
• 企业人口统计学信息
• 方法论
• 结语

开发者感受

Go 开发者继续报告他们对 Go 生态系统的高度满意。绝大多数受访者表示他们在过去一年中使用 Go 工作时感到满意（90% 满意，6% 不满意），其中大多数（52%）甚至表示他们“非常满意”，这是最高评分。长期读者可能已经注意到这个数字每年变化不大。对于像 Go 这样大型、稳定的项目来说，这是预期中的情况；我们将此指标视为一个滞后指标，可以帮助确认 Go 生态系统中普遍存在的问题，但我们不期望在这里首次发现潜在的问题。

我们通常发现，使用 Go 的时间越长，就越有可能报告对 Go 感到满意。这一趋势在 2023 年仍在持续；在 Go 经验不足一年的受访者中，82% 报告对 Go 开发体验感到满意，而 Go 经验五年或以上的开发者中这一比例为 94%。造成这种情况的因素可能多种多样，例如有些受访者随着时间的推移开始欣赏 Go 的设计选择，或者决定 Go 不适合他们的工作，因此在接下来的几年中不再参与此调查（即幸存者偏差）。尽管如此，这些数据有助于我们量化 Go 开发者当前的入门体验，显然我们可以做更多工作来帮助新兴的 Gophers 站稳脚跟，并在使用 Go 开发的早期获得成功。

关键的要点是，在过去一年中选择使用 Go 的绝大多数人都对他们的体验感到满意。此外，使用 Go 的人数持续增加；我们从外部研究中看到了证据，例如Stack Overflow 的开发者调查（发现 14% 的专业开发者在过去一年中使用 Go，同比增长约 15%），以及 go.dev 的分析数据（显示访客量同比增长 8%）。这种增长与高满意度分数相结合，证明 Go 对开发者仍然具有吸引力，并表明许多选择学习该语言的开发者在很久以后仍然对他们的决定感到满意。用他们自己的话说

“在从事了 30 多年 C、C++、Java 开发，以及现在七年的 Go 编程后，Go 仍然是迄今为止最具生产力的语言。它并不完美（没有任何语言是完美的），但它在生产力、复杂性和性能之间取得了最佳平衡。” — 拥有 5 – 9 年 Go 经验的专业开发者

“这是目前我所知道的最好的语言，我尝试过很多。工具很棒，编译时间很快，而且我真的非常高效。我很高兴有 Go 这个工具，而且我不需要在服务器端使用 TypeScript。谢谢。” — 拥有 3 – 4 年经验的开源 Go 开发者

开发者环境

与往年一样，大多数受访者告诉我们他们在 Linux (63%) 和 macOS (58%) 系统上使用 Go 进行开发。这些数字每年的微小变化很可能取决于谁发现了并回复了本次调查（特别是在 Go 博客上），因为我们没有看到来自 VS Code 随机样本的持续年度趋势。

我们确实继续看到，Go 社区的新成员比经验丰富的 Go 开发者更有可能在 Windows 上工作。我们将此解读为一个信号，表明基于 Windows 的开发对于新开发者加入 Go 生态系统非常重要，这是我们团队希望在 2024 年更多关注的主题。

受访者继续高度关注 Linux 部署。鉴于 Go 在云开发和容器化工作负载中的普及，这并不令人意外，但仍然是一个重要的确认。我们发现基于组织规模或经验水平等因素的差异很少；事实上，虽然新手 Go 开发者似乎更有可能在 Windows 上开发，但仍有 92% 的人部署到 Linux 系统。也许这种细分中最有趣的发现是，经验更丰富的 Go 开发者表示他们部署到更广泛的系统（最显著的是 WebAssembly 和 IoT），尽管尚不清楚这是因为此类部署对新 Go 开发者来说具有挑战性，还是经验丰富的 Go 开发者在更广泛的场景中使用 Go 的结果。我们还观察到，IoT 和 WebAssembly 在近年来都稳步增长，分别从 2021 年的 3% 上升到 2023 年的 6% 和 5%。

过去几年，计算架构格局发生了变化，我们在 Go 开发者目前使用的架构中看到了这种反映。虽然 x86 兼容系统仍占开发的绝大多数（89%），但 ARM64 现在也被大多数受访者使用（56%）。这种采用似乎部分是由 Apple Silicon 推动的；macOS 开发者现在表示他们为 ARM64 而不是基于 x86 的架构开发的可能性更高（76% 对 71%）。然而，Apple 硬件并非推动 ARM64 采用的唯一因素：在根本不在 macOS 上开发的受访者中，仍有 29% 表示他们为 ARM64 开发。

在 Go 开发者调查的受访者中，最常用的代码编辑器仍然是 VS Code (44%) 和 GoLand (31%)。这两个比例均较 2023 年上半年（分别为 46% 和 33%）略有下降，但仍在本次调查的误差范围内。在“其他”类别中，Helix 占了大多数回复。与上面提到的操作系统结果类似，我们不认为这代表着代码编辑器使用的显著变化，而只是反映了社区调查中预期会出现的一些变异性。特别是，对于这个问题，我们排除了来自 VS Code 的随机抽样受访者，因为我们知道该群体偏向于 VS Code。然而，这样做的一个副作用是使这些结果每年更容易出现波动。

我们还根据受访者偏好的编辑器来考察他们对 Go 的满意度。在控制了经验年限后，我们发现没有差异：我们不认为人们对 Go 的喜爱程度会因他们使用的代码编辑器而有所不同。这并不一定意味着所有 Go 编辑器都是平等的，但可能反映出人们找到了最适合自己需求的编辑器。这表明 Go 生态系统拥有健康的编辑器多样性，它们面向不同的用例和开发者偏好。

技术栈

为了更好地了解 Go 开发者所交互的软件和服务网络，我们问了几个关于技术栈的问题。我们将这些结果分享给社区，以展示当前常用的工具和平台，但我们相信每个人在选择技术栈时都应该考虑自己的需求和用例。更直白地说：我们既不希望读者仅仅因为某个组件流行就使用它来选择技术栈，也不希望他们因为某个组件不常用就避免使用它。

首先，我们可以自信地说，Go 是一种适用于现代云原生开发的语言。事实上，75% 的受访者使用与云服务集成的 Go 软件。近一半的受访者涉及 AWS (48%)，近三分之一的人使用 GCP (29%) 进行 Go 开发和部署。对于 AWS 和 GCP，其使用在大企业和小型组织之间均衡分布。微软 Azure 是唯一一个在大组织（员工人数 > 1,000 人的公司）中比小型公司显著更常使用的云提供商；其他提供商的使用情况与组织规模没有显著差异。

数据库是软件系统中极其常见的组件，我们发现 91% 的受访者表示他们使用的 Go 服务至少使用一个数据库。最常见的是 PostgreSQL (59%)，但同时有两位数比例的受访者报告使用了另外六种数据库，可以说 Go 开发者需要考虑的标准数据库并非只有少数几种。我们再次看到基于组织规模的差异，小型组织的受访者更倾向于报告使用 PostgreSQL 和 Redis，而大型组织的开发者则更倾向于使用特定于其云提供商的数据库。

受访者报告使用的另一个常见组件是缓存或键值存储；68% 的受访者表示他们使用的 Go 软件至少包含其中一种。Redis 显然是最常见的 (57%)， etcd (10%) 和 memcached (7%) 紧随其后。

与数据库类似，受访者告诉我们他们使用各种不同的可观测性系统。Prometheus 和 Grafana 是最常被提及的（均为 43%），而 Open Telemetry、Datadog 和 Sentry 的使用率也都在两位数。

如果有人想知道“我们是否将所有东西都 JSON 化了？”……是的，我们确实这样做了。几乎所有受访者（96%！）都表示他们的 Go 软件使用 JSON 数据格式；这在自报数据中几乎可以说是普遍的。YAML、CSV 和 protocol buffers 也都被约一半的受访者使用，TOML 和 XML 的使用比例也都在两位数。

对于身份验证和授权服务，我们发现大多数受访者是基于 JWT 和 OAuth2 等标准提供的基础进行构建的。这似乎也是一个组织选择其云提供商解决方案的可能性与大多数即用型替代方案差不多的领域。

最后，我们还有一些不完全符合上述类别的其他服务。我们发现近一半的受访者在他们的 Go 软件中使用了 gRPC (47%)。对于基础设施即代码的需求，大约四分之一的受访者首选 Terraform。与 Go 一起使用的其他相当常见的技术包括 Apache Kafka、ElasticSearch、GraphQL 和 RabbitMQ。

我们还研究了哪些技术倾向于一起使用。虽然从这项分析中没有出现明确类似于经典LAMP 技术栈的东西，但我们确实发现了一些有趣的模式

• 全有或全无：每个类别（数据格式除外）都显示出强烈的相关性，即如果受访者在一个类别中回答“无”，他们很可能在所有其他类别中也回答“无”。我们将此解释为证据，表明少数用例不需要这些技术栈组件中的任何一个，但一旦用例需要其中任何一个，它很可能需要（或至少通过使用）不止一个组件来简化。
• 偏向跨平台技术：特定于提供商的解决方案（即，单一云平台独有的服务）并未被广泛采用。然而，如果受访者使用了一种特定于提供商的解决方案（例如，用于指标），他们也更有可能表示他们在其他领域（例如，数据库、身份验证、缓存等）使用了特定于云的解决方案。
• 多云：三大云平台最有可能涉及多云部署。例如，如果一个组织正在使用任何非 AWS 的云提供商，他们可能也在使用 AWS。这种模式在 Amazon Web Services 上最为明显，但在 Google Cloud Platform 和 Microsoft Azure 上也比较明显（程度较轻）。

开发者如何启动新的 Go 项目

作为我们对项目模板进行实验的一部分，我们想了解如今的 Go 开发者是如何启动新项目的。受访者告诉我们，他们面临的最大挑战是选择合适的项目结构方式 (54%) 以及学习如何编写符合 Go 习惯用法的代码 (47%)。正如两位受访者所说

“为新项目找到合适的结构和正确的抽象级别可能相当繁琐；寻找社区和企业中的知名项目作为参考可能会让人感到困惑，因为每个人的项目结构都不同” — 拥有 5 – 9 年 Go 经验的专业开发者

“如果 [Go 有一个] 工具链来创建 [项目] 的基本结构，例如 go init <project name> 用于 Web 或 CLI 项目，那将非常棒” — 拥有 3 – 4 年经验的专业开发者

新 Go 开发者更有可能遇到这些挑战：Go 经验不足两年的受访者中，遇到这些挑战的比例分别增加到 59% 和 53%。这两个方面都是我们希望通过 gonew 原型来改进的：模板可以为新 Go 开发者提供经过良好测试的项目结构和设计模式，并提供符合 Go 习惯用法的初始实现。这些调查结果帮助我们的团队将 gonew 的目标集中在 Go 社区最困扰的任务上。

大多数受访者告诉我们，他们在启动新 Go 项目时要么使用模板，要么从现有项目中复制粘贴代码 (58%)。在 Go 经验不足五年的受访者中，这一比例增加到近 ⅔ (63%)。这是一个重要的确认，表明 gonew 中基于模板的方法似乎符合开发者现有的习惯，将一种常见的、非正式的方法与 go 命令风格的工具对齐。项目模板的常见功能需求进一步支持了这一点：大多数受访者要求 1) 预配置的目录结构来组织他们的项目，以及 2) 项目领域中常见任务的示例代码。这些结果与开发者在上一节中提到的挑战非常吻合。对此问题的回答也有助于区分项目结构和设计模式，希望 Go 项目模板提供前者（项目结构）的受访者数量是希望提供后者（设计模式）的两倍左右。

大多数受访者告诉我们，修改模板并将这些更改传播到基于该模板的项目中的能力至少具有中等重要性。从轶事来看，我们尚未与任何当前通过自制模板方法实现此功能的开发者交流过，但这表明这是一个有趣的未来发展方向。

开发者对错误处理的目标

Go 开发者中一个经久不衰的讨论话题是错误处理的潜在改进。正如一位受访者总结的那样

“错误处理增加了太多样板代码（我知道，你们可能之前已经听过这个说法了）” — 拥有 1 – 2 年经验的开源 Go 开发者

但是，我们也听到许多开发者表示他们欣赏 Go 的错误处理方法

“Go 的错误处理简单而有效。由于我使用 Java 和 C# 开发后端，现在正在探索 Rust 和 Zig，我总是很高兴回到 Go 编写代码。其中一个原因，信不信由你，就是错误处理。它真的简单、直接且有效。请保持这样。” — 拥有 5 – 9 年经验的开源 Go 开发者

我们没有询问 Go 中错误处理的具体修改，而是希望更好地了解开发者更高层次的目标以及 Go 当前的方法是否已被证明有用和易用。我们发现大多数受访者赞赏 Go 的错误处理方法 (55%)，并表示它帮助他们知道何时检查错误 (50%)。对于拥有更多 Go 经验的受访者来说，这两个结果更为显著，这表明开发者可能随着时间的推移越来越欣赏 Go 的错误处理方法，或者这是导致开发者最终离开 Go 生态系统（或至少不再回复 Go 相关调查）的一个因素。许多受访者还认为，Go 需要大量繁琐的样板代码来检查错误 (43%)；无论受访者拥有多少 Go 经验，这种情况都存在。有趣的是，当受访者表示他们赞赏 Go 的错误处理时，他们不太可能同时表示这导致大量样板代码——我们的团队曾假设 Go 开发者既可以欣赏该语言的错误处理方法，又觉得它过于冗长，但只有 14% 的受访者同时同意这两项说法。

受访者提到的具体问题包括难以知道要检查哪些错误类型 (28%)，希望轻松显示包含错误消息的堆栈跟踪 (28%)，以及错误可以被完全忽略的易用性 (19%)。大约 ⅓ 的受访者也对采用其他语言中的概念感兴趣，例如 Rust 的 ? 运算符 (31%)。

Go 团队没有计划向该语言添加异常，但由于从轶事上看这是一个常见的请求，我们将其作为回复选项。只有十分之一的受访者表示他们希望能在 Go 中使用异常，而且这与经验成反比——资深 Go 开发者比新加入 Go 社区的受访者对异常的兴趣更低。

了解 ML/AI 使用场景

Go 团队正在考虑新兴的 ML/AI 技术格局可能如何从两个不同的方面影响软件开发：1) ML/AI 工具如何帮助工程师编写更好的软件，以及 2) Go 如何帮助工程师将 ML/AI 支持引入他们的应用程序和服务？下面，我们将深入探讨这些领域。

帮助工程师编写更好的软件

毫无疑问，我们正处于关于 AI/ML 可能性的炒作周期中。我们希望退后一步，关注开发者面临的更广泛挑战，以及他们认为 AI 在日常工作中可能在哪些方面证明有用。答案有些出人意料，特别是考虑到行业目前对代码助手的关注。

首先，我们看到一些约一半受访者认为可能有用的 AI 用例：生成测试 (49%)，在现场提出最佳实践建议 (47%)，以及在开发过程早期捕获可能的错误 (46%)。这些首要用例的共同主题是，它们都可以帮助提高工程师所编写代码的质量和可靠性。第四个用例（帮助编写文档）获得了约 ⅓ 受访者的兴趣。其余用例构成了潜在有益想法的长尾，但它们的一般兴趣远低于前四个。

当我们考察开发者使用 Go 的经验年限时，我们发现新手受访者比资深 Go 开发者更关心解决编译器错误和解释 Go 代码片段的作用。这些可能是 AI 可以帮助改善新 Gophers 入门体验的领域；例如，AI 助手可以用自然语言解释一段未文档化的代码的作用，或为特定的错误消息提供常见解决方案。相反，我们发现对于“捕获常见错误”等主题，不同经验水平的开发者没有差异——无论是新手还是资深 Go 开发者都表示他们会很欢迎能提供这类帮助的工具。

仔细审视这些数据，可以看到三个广泛的趋势

1. 受访者表示有兴趣从“专家审阅者”那里获得实时反馈，而不仅仅是在审阅时。
2. 总的来说，受访者似乎对那些能让他们摆脱潜在不愉快任务（例如，编写测试或文档代码）的工具最感兴趣。
3. 完全由 AI 编写或翻译代码的兴趣相当低，特别是对于具有一年或两年以上经验的开发者而言。

综上所述，目前开发者似乎对机器承担软件开发中有趣（例如，创造性的、令人愉快的、适度具有挑战性的）部分的期望较低，但确实看到有另一双“眼睛”审阅他们的代码并可能为他们处理枯燥或重复性任务的价值。正如一位受访者所说

“我特别有兴趣使用 AI/ML 来提高我在 Go 方面的生产力。如果有一个系统经过 Go 最佳实践训练，能够捕获反模式、错误，生成测试，并且幻觉率低，那将是杀手级的。” — 拥有 5 – 9 年经验的专业开发者

然而，本次调查只是快速发展的研究领域中的一个数据点，因此最好在情境中理解这些结果。

将 AI 功能引入应用程序和服务

除了研究 Go 开发者如何从 AI/ML 支持的工具中获益外，我们还探讨了他们使用 Go 构建 AI 驱动的应用程序和服务（或支持基础设施）的计划。我们发现目前仍处于采用曲线的早期阶段：大多数受访者尚未尝试在这些领域使用 Go，尽管每个主题都吸引了大约一半受访者的兴趣。例如，大多数受访者表示有兴趣将其使用的 Go 服务与 LLM 集成 (49%)，但只有 13% 的人已经这样做或正在评估此用例。在本次调查时，回复温和地表明，开发者可能最感兴趣的是使用 Go 直接调用 LLM，构建支持 ML/AI 系统所需的数据管道，以及创建供其他服务调用以与 ML/AI 模型交互的 API 端点。举例来说，这位受访者描述了他们希望在数据管道中使用 Go 获得的好处

“我希望使用 Go 集成 ETL [提取、转换和加载] 部分，以保持一致、健壮、可靠的代码库。” — 拥有 3 – 4 年经验的专业开发者

工具链错误消息

许多开发者都能理解看到错误消息时的沮丧经历，以为自己知道它是什么意思以及如何解决，但在经过数小时徒劳的调试后才意识到它完全是另一个意思。一位受访者解释了他们的沮丧如下

“通常情况下，打印出来的错误信息与问题本身毫无关系，但我可能要花一个小时才能发现这一点。错误消息简洁得令人不安，而且似乎并没有尽力去猜测用户可能在尝试做什么，或者[解释他们]做错了什么。” — 拥有 10 年以上经验的专业开发者

我们认为开发者工具发出的警告和错误应该简短、易于理解且可操作：阅读它们的人应该能够准确理解哪里出了问题以及他们可以做什么来解决问题。这无疑是一个高标准，通过本次调查，我们进行了一些测量来了解开发者如何看待 Go 当前的警告和错误消息。

当回忆他们最近遇到的 Go 错误消息时，受访者表示仍有很大改进空间。只有一小部分人仅凭错误消息就能理解问题所在 (54%)，而知道下一步如何解决问题的比例更低 (41%)。似乎相对少量的额外信息可以显著提高这些比例，因为 ¼ 的受访者表示他们基本知道如何修复问题，但需要先看到示例。此外，有 11% 的受访者表示他们无法理解错误消息，这为我们提供了 Go 工具链错误消息当前可理解性的基线数据。

改进 Go 的工具链错误消息将特别有利于经验不足的 Gophers。拥有两年以下经验的受访者比资深 Gophers 更不可能表示他们理解问题 (47% 对 61%) 或知道如何修复 (29% 对 52%)，并且需要在线搜索来修复问题 (21% 对 9%) 甚至理解错误意味着什么 (15% 对 7%) 的可能性是后者的两倍。

我们希望在 2024 年重点改进工具链错误消息。这些调查结果表明，这是所有经验水平的开发者感到沮丧的一个领域，并且将特别有助于新开发者入门 Go。

为了理解这些消息如何改进，我们向受访者提出了一个开放式问题：“如果你可以许一个愿望，改进 Go 工具链中的一项错误消息，你会改变什么？”。回复在很大程度上与我们的假设一致，即好的错误消息既易于理解又可操作。最常见的回复是某种形式的“帮助我理解导致此错误的原因” (36%)，21% 的受访者明确要求提供修复问题的指导，14% 的受访者提及了 Rust 或 Elm 等语言作为在这两方面都做得很好的典范。用一位受访者的话来说

“对于编译错误，希望有 Elm 或 Rust 风格的输出，能精确定位源代码中的问题。错误应尽可能包含修复建议……我认为‘优化错误输出使其易于人类阅读’并‘在可能的情况下提供建议’的总体策略将非常受欢迎。” — 拥有 5 – 9 年经验的专业开发者

可以理解的是，工具链错误消息和运行时错误消息之间存在模糊的概念边界。例如，其中一项主要请求是改进堆栈跟踪或其他有助于调试运行时崩溃的方法 (22%)。类似地，4% 的反馈中有一个令人惊讶的主题是关于从 go 命令本身获取帮助的挑战。这些都是 Go 社区帮助我们识别相关痛点的好例子，这些痛点原本不在我们的关注范围内。我们最初的调查重点是改进编译时错误，但 Go 开发者希望改进的核心领域之一实际上与运行时错误有关，而另一个是关于 go 命令的帮助系统。

“抛出错误时，调用堆栈可能非常大，包含一堆我不关心的文件。我只想知道问题出在我的代码的哪个位置，而不是我正在使用的库，或者 panic 是如何处理的。” — 拥有 1 – 2 年经验的专业开发者

“通过 go help run 获取帮助会输出一大堆文本，以及指向进一步阅读以查找可用命令行标志的链接。或者它能理解 go run –help，但不是显示帮助信息，而是说‘请改用 go help run’。直接在 go run –help 中显示标志列表就好。” — 拥有 3 – 4 年经验的专业开发者

微服务

我们常听到开发者认为 Go 非常适合微服务，但我们从未尝试量化有多少 Go 开发者采用了这种服务架构，了解这些服务之间如何通信，或开发者在开发微服务时遇到的挑战。今年我们增加了一些问题，以便更好地了解这个领域。

多数受访者表示他们主要从事微服务开发 (43%)，另有 ¼ 的人表示他们同时从事微服务和单体应用开发。只有约 ⅕ 的受访者主要从事 Go 单体应用程序开发。这是我们看到基于受访者所在组织规模的少数几个差异领域之一——大型组织似乎比小型公司更有可能采用微服务架构。大型组织（员工人数 > 1,000 人）的受访者最有可能表示他们从事微服务开发 (55%)，其中只有 11% 的受访者主要从事单体应用开发。

我们看到构成 Go 平台的微服务数量存在一些分歧。一组由少数（2 到 5 个）服务组成 (40%)，而另一组由更庞大的集合组成，至少包含 10 个组件服务 (37%)。所涉及的微服务数量似乎与组织规模无关。

绝大多数受访者使用某种形式的直接响应请求（例如，RPC、HTTP 等）进行微服务通信 (72%)。较小比例的受访者使用消息队列 (14%) 或发布/订阅方法 (9%)；同样，我们在此没有看到基于组织规模的差异。

大多数受访者使用多种语言构建微服务，其中只有约四分之一专门使用 Go。Python 是最常见的伴随语言（33%），其次是 Node.js（28%）和 Java（26%）。我们再次看到基于组织规模的差异，规模较大的组织更倾向于整合 Python (43%) 和 Java (36%) 微服务，而规模较小的组织则稍微更倾向于仅使用 Go (30%)。根据组织规模来看，其他语言的使用比例似乎相当。

总体而言，受访者告诉我们，在编写基于微服务的应用程序时，测试和调试是他们最大的挑战，其次是操作复杂性。许多其他挑战则占据了图表的长尾部分，不过“可移植性”对大多数受访者而言并非问题。我们将其解读为：此类服务无意实现可移植性（超出基本的容器化）；例如，如果一个组织的微服务最初使用 PostgreSQL 数据库，开发者并不担心在不久的将来可能将其移植到 Oracle 数据库。

模块编写和维护

Go 拥有一个由社区驱动的充满活力的模块生态系统，我们希望了解维护这些模块的开发者所面临的动机和挑战。我们发现，大约五分之一的受访者维护（或曾经维护）一个开源 Go 模块。这是一个出人意料高的比例，并且可能由于我们分享此调查的方式而产生偏差：模块维护者可能比其他 Go 开发者更倾向于密切关注 Go 博客（此调查在此处发布）。

模块维护者似乎主要是自我驱动的——他们表示维护自己个人（58%）或工作（56%）项目所需的模块，这样做是因为他们享受维护这些模块（63%）和成为 Go 公共社区的一部分（44%），并且从模块维护中学到有用的技能（44%）。更外部的动机，例如获得认可（15%）、职业发展（36%）或经济报酬（20%），则处于列表的底部。

考虑到上述确定的内在动机形式，模块维护者面临的一个关键挑战是找到时间投入到他们的模块中 (41%)。虽然这本身可能看起来不是一个可操作的发现（我们无法每天给 Go 开发者额外的一两个小时，对吧？），但这提供了一个有用的视角来审视模块工具和开发——这些任务很可能发生在开发者时间已经很紧张的情况下，而且距离他们上次有机会处理这些任务可能已经过去几周或几个月了，因此记忆并不清晰。因此，诸如易于理解且可操作的错误消息等方面会特别有帮助：与其要求某人再次搜索特定的 go 命令语法，错误输出也许可以直接在他们的终端中提供他们所需的解决方案。

人口统计学信息

大多数受访者表示他们在主要工作中使用 Go (78%)，并且大多数 (59%) 表示他们将其用于个人或开源项目。实际上，受访者将 Go 同时用于工作和个人/开源项目是很常见的，有 43% 的受访者表示他们在每种情况下都使用 Go。

大多数受访者使用 Go 的时间不到五年 (68%)。正如我们在前几年看到的，通过 VS Code 找到此调查的人往往比通过其他渠道找到调查的人经验更少。

当我们按经验水平细分人们使用 Go 的情况时，有两项发现非常突出。首先，所有经验水平的大多数受访者都表示他们在职业上使用 Go；事实上，对于经验两年以上的人来说，绝大多数在工作中使用 Go (85% – 91%)。开源开发也有类似的趋势。第二个发现是，Go 经验较少的开发者比经验丰富的 Go 开发者更有可能使用 Go 来扩展他们的技能 (38%) 或评估其在工作中的用途 (13%)。我们将其解读为，许多 Gopher 最初将 Go 视为“提升技能”或扩展他们对软件开发的理解的一部分，但在一年或两年内，他们更多地将 Go 视为一种用于“做”的工具，而非学习的工具。

Go 最常见的用例仍然是 API/RPC 服务 (74%) 和命令行工具 (62%)。人们告诉我们，Go 是这些类型软件的绝佳选择，原因有几个，包括其内置的 HTTP 服务器和并发原语、易于交叉编译以及单二进制部署。

这些工具的大部分预期受众是在商业环境 (62%) 中，有 17% 的受访者表示他们主要为更面向消费者的应用程序开发。考虑到 Go 在桌面、移动或游戏等面向消费者的应用程序中的使用率较低，而其在后端服务、CLI 工具和云开发中的使用率非常高，这并不令人意外，但这有力地证实了 Go 在 B2B 环境中的高度使用。

我们还根据受访者对 Go 的经验水平和组织规模寻找差异。经验更丰富的 Go 开发者表示使用 Go 构建的项目类型更广泛；这一趋势在每种应用或服务类别中都保持一致。我们没有发现受访者基于其组织规模所构建项目有任何显著差异。

受访者表示这是他们第一次回应 Go 开发者调查的可能性与表示他们之前参加过此调查的可能性大致相等。通过 Go 博客得知此调查的人（其中 61% 报告之前参加过此调查）与通过 VS Code 通知得知此调查的人（其中只有 31% 表示之前参加过此调查）之间存在显著差异。我们不指望人们完美记住他们在线上回答过的每一个调查，但这让我们有信心，每次调查都能听到新受访者和重复受访者的均衡组合的意见。此外，这告诉我们，结合社交媒体帖子和编辑器内随机抽样对于听取多元化的 Go 开发者群体的意见都是必要的。

企业人口统计学信息

本次调查的受访者表示他们在各种不同的组织工作，从千人以上的大型企业 (27%)，到中型企业 (25%) 和员工数少于 100 人的小型组织 (44%)。约一半的受访者在科技行业工作 (50%)，这比下一个最常见的行业——金融服务 (13%)——有大幅增长。

这与过去几年的 Go 开发者调查在统计上没有变化——我们年复一年地以一致的比例听取来自不同国家、不同规模和行业的组织的人们的意见。

方法论

大多数调查受访者是“自选”参加本次调查的，这意味着他们在 Go 博客或其他 Go 社交渠道上发现了它。这种方法的一个潜在问题是，不关注这些渠道的人不太可能了解此调查，并且他们的回应可能与密切关注这些渠道的人不同。约 40% 的受访者是随机抽样的，这意味着他们在 VS Code 中看到调查提示后回应了调查（在 2023 年 7 月中旬至 8 月中旬期间使用 VS Code Go 插件的每个人都有 10% 的概率收到此随机提示）。这个随机抽样的群体帮助我们将这些发现推广到更广泛的 Go 开发者社区。

如何解读这些结果

在本报告中，我们全程使用调查回应图表来为我们的发现提供支持证据。所有这些图表都采用类似的格式。标题是受访者看到的 exact 问题。除非另有说明，问题均为多项选择，参与者只能选择一个回应选项；每个图表的副标题将告知读者问题是否允许多个回应选项或是一个开放式文本框而非多项选择题。对于开放式文本回应的图表，由一名 Go 团队成员阅读并手动对回应进行分类。许多开放式问题引发了广泛的回应；为了保持图表尺寸合理，我们将它们浓缩至最多前 10 个主题，其余主题均归入“其他”组。图表中显示的百分比标签四舍五入到最接近的整数（例如，1.4% 和 0.8% 都将显示为 1%），但每个条形图的长度和行的排序基于未四舍五入的值。

为了帮助读者理解每个发现背后的证据权重，我们包含了显示回应的 95% 置信区间的误差条；误差条越窄表示置信度越高。有时两个或多个回应的误差条会重叠，这意味着这些回应的相对顺序在统计上没有意义（即，这些回应实际上是并列的）。每个图表的右下角显示了包含在图表中的回应人数，形式为“n = [受访者人数]”。

我们精选了受访者的引述，以帮助阐明我们的许多发现。这些引述包括受访者使用 Go 的时长。如果受访者表示他们在工作中使用 Go，我们称他们为“专业 Go 开发者”；如果他们不在工作中使用 Go 但用于开源开发，我们称他们为“开源 Go 开发者”。

结语

我们调查的最后一个问题总是询问受访者是否有其他关于 Go 的内容想与我们分享。人们提供的最常见的反馈是“谢谢！”，今年也不例外 (33%)。在建议的语言改进方面，我们看到统计上并列排在前三位的是：改进表达能力 (12%)、改进错误处理 (12%) 以及改进类型安全或可靠性 (9%)。受访者提出了各种改进表达能力的想法，这些反馈的总体趋势是“这是我经常编写的特定内容，我希望在 Go 中更容易表达”。错误处理的问题仍然集中在对当前代码冗余的抱怨，而关于类型安全的反馈最常见地提到了和类型。这种高层面的反馈对于 Go 团队规划来年的重点领域极其有用，因为它告诉我们社区希望生态系统朝着哪个总体方向发展。

“我知道 Go 对简洁的态度，我很欣赏它。我只是希望有一些稍微更多的特性。对我来说，这将是更好的错误处理（但不是异常），也许还有一些常见的便利功能，比如 map/reduce/filter 和三元运算符。任何不太晦涩的东西，只要能帮我省去一些‘if’语句就行。” — 拥有 1-2 年经验的专业 Go 开发者

“请让 Go 继续保持 Go 很久以前建立的长期价值观——语言和库的稳定性。[...] 这是一个我可以信赖的环境，我的代码在两三年后也不会被破坏。为此，非常感谢。” — 拥有 10 年以上经验的专业 Go 开发者

本期半年一次的 Go 开发者调查到此结束。感谢所有分享了他们对 Go 反馈的人——我们非常感激您抽出宝贵时间帮助塑造 Go 的未来，希望您能在本报告中看到您自己的一些反馈的体现。🩵

— Todd（代表 Google Go 团队）