背景

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

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

简而言之

1. Go 开发者表示，他们“对能提高代码质量、可靠性和性能的 AI/ML 工具更感兴趣”，而不是希望 AI 直接为他们编写代码。一个永远在线、从不忙碌的专家“评审员”可能是 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 的时间越长，他们就越可能报告对此感到满意。这一趋势在 2023 年得以延续；在 Go 经验不足一年的受访者中，82% 的人报告对 Go 开发体验感到满意，而拥有五年或更长 Go 经验的开发者则有 94% 的人表示满意。这可能有很多因素在起作用，例如一些受访者随着时间的推移对 Go 的设计选择有了更深的 appreciation，或者决定 Go 不适合他们的工作，因此在后续年份不再回复此调查（即“幸存者偏差”）。尽管如此，这些数据有助于我们量化 Go 开发者当前的入门体验，并且显然我们可以做得更多，以帮助新兴的 Gopher 们站稳脚跟，并在 Go 开发中取得早期成功。

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

“在 C、C++、Java 开发了 30 多年后，现在我用 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，无论大型企业还是小型组织，使用情况都相对均衡。Microsoft Azure 是唯一一个在大型组织（拥有 >1000 名员工的公司）中比小型公司使用可能性明显更高的云提供商；其他提供商在使用方面与组织规模没有有意义的差异。

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

受访者报告使用的另一个常见组件是缓存或键值存储；68% 的受访者表示他们从事包含至少一个此类组件的 Go 软件开发。Redis 明显是最常见的（57%），其次是 etcd (10%) 和 memcached (7%)。

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

以免有人问“我们是不是已经把所有东西都 JSON 化了？”……是的，我们已经 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 有一个工具链可以像 `go init ` 一样为 Web 或 CLI 创建项目的基本结构，那就太好了。” — 拥有 3-4 年经验的专业 Go 开发者

新手 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 可以改善新手 Gopher 入门体验的领域；例如，AI 助手可以帮助用自然语言解释未文档化的代码块的作用，或者为特定的错误消息建议常见解决方案。相反，在“捕获常见错误”等主题上，我们发现经验水平之间没有差异——新手和资深 Go 开发者都表示他们会感谢有工具来帮助解决这个问题。

我们可以从这些数据中看到三个大的趋势：

1. 受访者表示有兴趣实时获得“专家评审员”的反馈，而不仅仅是在代码评审时。
2. 总的来说，受访者似乎最感兴趣的是那些能让他们摆脱不那么令人愉快的任务（例如，编写测试或记录代码）的工具。
3. wholesale 编写或翻译代码的兴趣相当低，尤其是对于有两年以上经验的开发者。

总而言之，今天开发者似乎对机器从事软件开发中有趣的部分（例如，创造性、令人愉悦、有适当挑战性）的前景不那么兴奋，但确实看到了让另一双“眼睛”评审他们的代码并可能处理乏味或重复任务的价值。正如一位受访者所说：

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

然而，这项调查只是一个快速发展的研究领域中的一个数据点，因此最好将这些结果置于上下文中。

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

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

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

工具链错误消息

许多开发者都能体会到看到错误消息，认为自己知道它的含义和如何解决，但经过数小时的徒劳调试才发现它实际上意味着别的东西的令人沮丧的经历。一位受访者解释了他们的沮丧：

“印刷的抱怨经常与问题无关，但这可能需要一个小时我才发现事实并非如此。错误消息异常简洁，似乎也不会费心去猜测用户可能想做什么或 [解释他们] 做错了什么。” — 拥有 10 多年经验的专业 Go 开发者

我们认为开发工具发出的警告和错误应该是简洁、易于理解和可操作的：阅读它们的人应该能够准确地理解出了什么问题以及他们可以采取什么措施来解决问题。这不可否认是一个很高的目标，通过本次调查，我们对开发者如何看待 Go 当前的警告和错误消息进行了一些衡量。

在思考他们最近处理的 Go 错误消息时，受访者告诉我们改进空间很大。只有一小部分人能仅从错误消息中理解问题（54%），甚至更少的人知道下一步该做什么来解决问题（41%）。似乎少量额外的信息就可以显著提高这些比例，因为四分之一的受访者表示他们大致知道如何修复问题，但需要先看到一个例子。此外，有 11% 的受访者表示他们无法理解错误消息，这为 Go 工具链错误消息的当前可理解性提供了一个基准。

改进 Go 工具链错误消息将尤其惠及经验较少的 Gopher。经验不足两年的受访者比资深 Gopher 更不可能表示他们理解问题（47% vs. 61%）或知道如何修复它（29% vs. 52%），并且更有可能需要在线搜索来修复问题（21% vs. 9%）甚至理解错误含义（15% vs. 7%）。

我们希望在 2024 年专注于改进工具链错误消息。这些调查结果表明，这是所有经验水平开发者的一个痛点，并将尤其有助于新手开发者入门 Go。

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

“对于编译错误，Elm 或 Rust 风格的输出可以精确地指出源代码中的问题。错误应包含修复建议……我认为‘优化错误输出以供人类阅读’并‘在可能的情况下提供建议’的通用政策将非常受欢迎。” — 拥有 5-9 年经验的专业 Go 开发者

可以理解的是，工具链错误消息和运行时错误消息之间存在概念上的模糊界限。例如，最常见的请求之一涉及改进堆栈跟踪或其他帮助调试运行时崩溃的方法（22%）。同样，4% 的反馈中有一个令人惊讶的主题是关于从 `go` 命令本身获取帮助的挑战。这些是 Go 社区帮助我们识别我们之前未曾注意到的相关痛点的绝佳范例。我们开始这项调查的重点是改进编译时错误，但 Go 开发者希望看到改进的核心领域之一实际上与运行时错误有关，而另一个则与 `go` 命令的帮助系统有关。

“当抛出错误时，调用堆栈可能很大，并且包含大量我不在乎的文件。我只想知道我代码中的问题所在，而不是我使用的库，或者 panic 是如何处理的。” — 拥有 1-2 年经验的专业 Go 开发者

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

微服务

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

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

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

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

大多数受访者使用多种语言构建微服务，只有约四分之一的受访者仅使用 Go。Python 是最常见的伴随语言（33%），其次是 Node.js (28%) 和 Java (26%)。我们再次看到基于组织规模的差异，大型组织更有可能集成 Python (43%) 和 Java (26%) 微服务，而小型组织则更可能仅使用 Go (30%)。其他语言的使用似乎与组织规模无关。

总体而言，受访者告诉我们，测试和调试是他们在编写基于微服务的应用程序时面临的最大挑战，其次是运维复杂性。许多其他挑战占据了此图表的长尾，尽管“可移植性”对大多数受访者来说似乎不是一个问题。我们将其解释为，这些服务并非设计为可移植的（除了基本的容器化）；例如，如果一个组织的微服务最初由 PostgreSQL 数据库提供支持，那么开发者就不担心将来可能将其移植到 Oracle 数据库。

模块的编写和维护

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

模块维护者似乎主要是自我激励的——他们报告说开发他们需要的个人（58%）或工作（56%）项目模块，他们这样做是因为他们喜欢处理这些模块（63%）并成为 Go 公共社区的一部分（44%），并且他们从模块维护中学习有用的技能（44%）。更外部的动机，如获得认可（15%）、职业发展（36%）或金钱（20%）则排在列表的后半部分。

考虑到上述的“内在动机”形式，因此，模块维护者的一个关键挑战是找到时间投入到他们的模块中（41%）。虽然这本身可能不是一个可操作的发现（我们不能给 Go 开发者每天多一两个小时，对吧？），但它为查看模块工具和开发提供了一个有用的视角——这些任务很可能发生在开发者已经时间紧迫的时候，并且可能已经几周或几个月没有机会处理它了，所以事情并不新鲜。因此，易于理解和可操作的错误消息等方面可以特别有帮助：与其要求某人再次搜索特定的 `go` 命令语法，不如错误输出可以直接在他们的终端中提供他们所需的解决方案。

人口统计

大多数调查受访者报告使用 Go 进行主要工作（78%），并且大多数人（59%）表示他们将其用于个人或开源项目。事实上，受访者经常同时将 Go 用于工作和个人/OSS 项目，43% 的受访者表示他们在每种情况下都使用 Go。

大多数受访者使用 Go 的时间不到五年（68%）。正如我们在往年所见，通过 VS Code 找到此调查的人往往比通过其他渠道找到调查的人经验较少。

当我们按经验水平细分人们使用 Go 的地方时，有两个发现脱颖而出。首先，所有经验水平的大多数受访者都表示他们正在专业地使用 Go；事实上，对于经验超过两年的人来说，绝大多数人在工作中都使用 Go（85% - 91%）。开源开发也存在类似的趋势。第二个发现是，Go 经验较少的开发者更有可能将 Go 用于扩展技能集（38%）或评估其在工作中的使用（13%），而不是经验丰富的 Go 开发者。我们将其解释为，许多 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 开发者社区。

如何解读这些结果

在整个报告中，我们使用调查回复图表来提供支持我们发现的证据。所有这些图表都采用了类似的格式。标题是调查受访者看到的精确问题。除非另有说明，问题都是多项选择题，参与者只能选择一个选项；每个图表的副标题将告知读者该问题是否允许多项选择或是一个开放式文本框而不是多项选择题。对于开放式文本回复的图表，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 早期设定的长期价值观一致——语言和库的稳定性……这是一个我可以依赖的环境，不会在 2 或 3 年后破坏我的代码。为此，非常感谢。” — 拥有 10 多年经验的专业 Go 开发者

以上是本期 Go 开发者调查的全部内容。感谢所有分享他们对 Go 反馈的人——我们非常感激您花费宝贵时间帮助塑造 Go 的未来，并希望您能在此报告中看到您自己的一些反馈。🩵

— Todd（代表 Google Go 团队）