Go 博客
Go 开发者调查 2023 H2 结果
背景
2023 年 8 月,Google 的 Go 团队对 Go 开发者进行了我们每半年一次的调查。我们通过 Go 博客上的公开帖子和 VS Code 中的随机提示招募了参与者,共收到 4,005 份回复。我们主要关注围绕以下几个主题的调查问题:使用 Go 开发的一般情绪和反馈、与 Go 结合使用的技术栈、开发者如何开始新的 Go 项目、最近在工具链错误消息方面的体验,以及了解开发者对 ML/AI 的兴趣。
感谢所有参与本次调查的人!这份报告分享了我们从您的反馈中了解到的内容。
tl;dr
- Go 开发者表示,他们**对提高他们编写的代码质量、可靠性和性能的 AI/ML 工具更感兴趣**,而不是为他们编写代码。始终在线、永不疲倦的专家“审查者”可能是 AI 开发者辅助中最有用的形式之一。
- 改进工具链警告和错误的首要要求是**使消息更易理解和操作**;所有经验水平的开发者都表达了这种观点,但在较新的 Go 开发者中尤为强烈。
- 我们对项目模板(
gonew
)的实验似乎解决了 Go 开发者(尤其是 Go 新手)的关键问题,并且以符合他们启动新项目的现有工作流程的方式实现了这一点。根据这些发现,我们相信**gonew
可以大幅降低 Go 新手的入门门槛,并简化 Go 在组织中的采用**。 - 每四个受访者中就有三个使用 Go 软件也使用云服务;这证明**开发者将 Go 视为现代云原生开发的语言**。
- **开发者对 Go 的情绪仍然非常积极**,90% 的调查受访者表示他们在过去一年中使用 Go 时感到满意。
内容
开发者情绪
Go 开发者继续报告对 Go 生态系统的较高满意度。大多数受访者表示他们在过去一年中使用 Go 时感到满意(90% 满意,6% 不满意),并且大多数人(52%)进一步表示他们“非常满意”,这是最高评级。长期读者可能已经注意到,这个数字年复一年变化不大。对于像 Go 这样的大型稳定项目来说,这是预料之中的;我们认为这个指标是一个滞后指标,可以帮助确认 Go 生态系统中普遍存在的问题,但这不是我们预期首先了解潜在问题的来源。
我们通常发现,使用 Go 的时间越长,就越有可能报告对 Go 的满意度。这种趋势在 2023 年继续保持;在 Go 经验少于一年的受访者中,82% 的人表示对 Go 开发体验感到满意,而 Go 开发经验五年或更长的受访者则达到了 94%。这其中可能存在多种因素,例如,一些受访者随着时间的推移逐渐认可 Go 的设计选择,或者认为 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 社区的较新成员使用 Windows 的可能性高于有经验的 Go 开发者。我们将其解释为一个信号,表明基于 Windows 的开发对于 Go 生态系统中的新开发者入门至关重要,是我们团队希望在 2024 年更多关注的主题。
受访者继续高度关注 Linux 部署。鉴于 Go 在云开发和容器化工作负载中的流行,这并不令人惊讶,但仍然是一个重要的确认。我们发现基于组织规模或经验水平等因素几乎没有有意义的差异;事实上,尽管 Go 新手似乎更可能在 Windows 上开发,但 92% 的人仍然在 Linux 系统上部署。也许从这种细分中得出的最有趣的发现是,更有经验的 Go 开发者表示,他们将 Go 部署到更广泛的系统(最显著的是 WebAssembly 和物联网),尽管目前尚不清楚这是因为这些部署对 Go 新手来说具有挑战性,还是经验丰富的 Go 开发者在更广泛的上下文中使用 Go 的结果。我们还观察到,物联网和 WebAssembly 在最近几年稳步增长,分别从 2021 年的 3% 上升到 2023 年的 6% 和 5%。
过去几年,计算架构格局发生了变化,我们也看到这种变化反映在 Go 开发者表示他们使用的当前架构中。虽然与 x86 兼容的系统仍然占大多数开发(89%),但 ARM64 现在也被大多数受访者使用(56%)。这种采用似乎部分由 Apple Silicon 驱动;macOS 开发者现在更有可能表示他们在 ARM64 上开发,而不是在基于 x86 的架构上开发(76% vs. 71%)。然而,Apple 硬件并非驱动 ARM64 采用的唯一因素:在完全没有在 macOS 上开发的受访者中,29% 的人仍然表示他们在 ARM64 上开发。
Go 开发者调查受访者中最常用的代码编辑器仍然是 VS Code(44%)和 GoLand(31%)。这两个比例都略微低于 2023 年 H1(分别为 46% 和 33%),但仍然在本次调查的误差范围内。“其他”类别中,Helix 占了大多数回复。与上面的操作系统结果类似,我们认为这并不代表代码编辑器使用情况的重大转变,而是显示出我们在这种社区调查中预期的某些可变性。尤其是,我们排除了来自 VS Code 的随机样本受访者,因为我们知道该组对 VS Code 有很大偏见。然而,这也会导致这些结果在每年都更容易出现变化。
我们还根据受访者偏爱的编辑器查看了他们对 Go 的满意度。在控制了经验长度后,我们没有发现任何差异:我们认为,人们对使用 Go 的体验没有更多或更少的享受,这并不一定意味着所有 Go 编辑器都是相同的,但这可能反映了人们会找到最适合他们自己需求的编辑器。这表明 Go 生态系统拥有健康的多样化的编辑器,针对不同的用例和开发者偏好。
技术栈
为了更好地了解 Go 开发者交互的软件和服务网络,我们问了几个关于技术栈的问题。我们与社区分享这些结果,以显示当今常用的工具和平台,但我们认为每个人在选择技术栈时都应该考虑自己的需求和用例。更直白地说:我们既不打算让读者使用这些数据来选择技术栈的组件,因为它们很受欢迎,也不打算避免使用组件,因为它们并不常见。
首先,我们可以自信地说,Go 是一种现代云原生开发的语言。事实上,75% 的受访者使用 Go 软件与云服务集成。对于近一半的受访者来说,这涉及到 AWS(48%),而几乎三分之一的受访者在他们的 Go 开发和部署中使用了 GCP(29%)。对于 AWS 和 GCP,大型企业和小型组织的应用率是相当平衡的。Microsoft 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 和协议缓冲区也被大约一半的受访者使用,还有两位数比例的受访者也使用 TOML 和 XML。
对于身份验证和授权服务,我们发现大多数受访者正在基于 JWT 和 OAuth2 等标准提供的基础进行构建。这似乎也是一个组织的云提供商的解决方案与大多数现成的替代方案一样有可能被使用的领域。
最后,我们还有一堆不适合上述类别的其他服务。我们发现,近一半的受访者在他们的 Go 软件中使用 gRPC (47%)。对于基础设施即代码需求,Terraform 是约四分之一受访者的首选工具。其他与 Go 一起使用的相当常见的技术包括 Apache Kafka、ElasticSearch、GraphQL 和 RabbitMQ。
我们还研究了哪些技术往往一起使用。虽然从这次分析中没有出现明显类似于经典的 LAMP 堆栈 的东西,但我们确实发现了一些有趣的模式。
- 全有或全无:除了数据格式之外,每个类别都显示出强烈的相关性,即如果受访者对某个类别回答“无”,他们很可能对所有其他类别也回答“无”。我们将其解释为一个证据,即只有少数用例不需要这些技术栈组件中的任何一个,但是一旦用例需要其中一个,它很可能需要 (或者至少会被) 不止一个简化。
- 偏向跨平台技术:提供商特定的解决方案 (即仅针对单个云平台的服务) 并不常见。但是,如果受访者使用了一个提供商特定的解决方案 (例如,用于指标),他们更有可能也表示他们使用了特定于云的解决方案来处理其他领域 (例如,数据库、身份验证、缓存等)。
- 多云:三个最大的云平台最有可能参与多云设置。例如,如果一个组织正在使用任何非 AWS 云提供商,那么他们可能也在使用 AWS。这种模式在亚马逊网络服务 (AWS) 中最为明显,但在 Google Cloud Platform 和 Microsoft Azure (程度较轻) 中也比较明显。
开发者如何开始新的 Go 项目
作为我们 项目模板实验 的一部分,我们想了解 Go 开发人员今天如何开始新的项目。受访者告诉我们,他们面临的最大挑战是选择一个合适的项目结构方式 (54%) 和学习如何编写惯用的 Go 代码 (47%)。正如两位受访者所说
“为新项目找到合适的结构和正确的抽象级别可能非常繁琐;查看知名社区和企业项目以寻求灵感可能会非常混乱,因为每个人都以不同的方式构建他们的项目” — 具有 5-9 年 Go 开发经验的专业 Go 开发人员
“如果 [Go 有一个] 工具链来为 web 或 CLI 创建 [项目的] 基本结构,例如 `go init <项目名称>`,那就太好了” — 具有 3-4 年 Go 开发经验的专业 Go 开发人员
Go 新手更有可能遇到这些挑战:对于 Go 开发经验少于两年的受访者,比例分别上升到 59% 和 53%。这两个方面都是我们希望通过我们的 gonew
原型来改进的:模板可以为 Go 新手提供经过良好测试的项目结构和设计模式,以及用惯用的 Go 代码编写的初始实现。这些调查结果帮助我们的团队将 gonew
的目的集中在 Go 社区最难处理的任务上。
大多数受访者告诉我们,他们在开始一个新的 Go 项目时要么使用模板,要么从现有项目中复制粘贴代码 (58%)。在 Go 开发经验少于五年的受访者中,这一比例上升到近三分之二 (63%)。这再次证明了 gonew
中基于模板的方法似乎满足了开发人员的现有需求,将一种常见的非正式方法与 go
命令式工具对齐。这一点也得到了对项目模板的常见功能需求的支持:大多数受访者要求 1) 一个预先配置的目录结构来组织他们的项目,以及 2) 项目领域中常见任务的示例代码。这些结果与开发人员在上一节中提到的挑战非常吻合。对这个问题的回答也有助于区分项目结构和设计模式,几乎两倍的受访者表示他们希望 Go 项目模板提供前者而不是后者。
大多数受访者告诉我们,能够修改模板并让这些更改传播到基于该模板的项目至少是中等重要性的。从轶事上看,我们还没有与任何目前使用自建模板方法的开发人员谈过,但这表明这是一个有趣的未来发展方向。
开发者对错误处理的目标
Go 开发人员之间永恒的话题是 Go 错误处理的潜在改进。正如一位受访者总结道
“错误处理增加了太多样板代码 (我知道,你可能之前也听说过)” — 具有 1-2 年 Go 开发经验的开源 Go 开发人员
但是,我们也从许多开发人员那里听到,他们很欣赏 Go 对错误处理的方法
“Go 错误处理既简单又有效。由于我现在在 Java 和 C# 中有后端,并且正在探索 Rust 和 Zig,我总是很高兴回到 Go 代码中。原因之一是,信不信由你,错误处理。它真的非常简单、直观且有效。请保持现状。” — 具有 5-9 年 Go 开发经验的开源 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 代码片段的含义。这些可能是人工智能可以帮助改善新手 Gophers 入门体验的领域;例如,人工智能助手可以帮助用自然语言解释未经文档化的代码块的作用,或建议解决特定错误消息的常见解决方案。相反,我们在“捕捉常见错误”等主题上没有看到经验水平之间的差异——新手和资深 Go 开发者都表示,他们希望使用工具来帮助解决这个问题。
我们可以仔细观察这些数据,并看到三种主要趋势。
- 受访者表示,他们希望能够实时获得“专家评审”的反馈,而不仅仅是在评审时间。
- 总的来说,受访者似乎最感兴趣的是可以帮助他们免除一些可能不太令人愉快的任务(例如,编写测试或编写文档)的工具。
- 对代码的大规模编写或翻译的兴趣相当低,尤其是对于具有超过一两年经验的开发者来说。
综上所述,似乎在今天,开发者对机器执行软件开发中有趣的部分(例如,创造性、令人愉快的、适当具有挑战性的)不太感兴趣,但确实看到了另一双“眼睛”审查他们的代码并可能为他们处理枯燥或重复性任务的价值。正如一位受访者所说
“我特别有兴趣使用人工智能/机器学习来提高我在 Go 中的生产力。拥有一个经过 Go 最佳实践训练的系统,能够捕捉反模式、错误、生成测试,并且幻觉率很低,这将是杀手级功能。” — 具有 5-9 年经验的专业 Go 开发者
然而,这份调查仅仅是快速发展的研究领域中的一个数据点,因此最好将这些结果放在背景中。
将人工智能功能引入应用程序和服务
除了关注 Go 开发者如何从人工智能/机器学习驱动的工具中获益外,我们还探讨了他们使用 Go 构建人工智能驱动的应用程序和服务(或支持基础设施)的计划。我们发现,我们仍然处于 采用曲线 的早期阶段:大多数受访者尚未尝试在这些领域使用 Go,尽管每个主题都从大约一半的受访者那里获得了某种程度的兴趣。例如,大多数受访者表示有兴趣将他们正在开发的 Go 服务与大型语言模型 (LLM) 整合 (49%),但只有 13% 的受访者已经这样做或正在评估此用例。在进行这份调查时,受访者表示,开发者可能最感兴趣的是使用 Go 直接调用大型语言模型,构建为机器学习/人工智能系统提供动力的数据管道,以及创建其他服务可以调用的 API 端点以与机器学习/人工智能模型进行交互。例如,一位受访者描述了他们希望通过在数据管道中使用 Go 获得的益处
“我想使用 Go 集成 ETL [提取、转换和加载] 部分,以保持一致、健壮、可靠的代码库。” — 具有 3-4 年经验的专业 Go 开发者
工具链错误消息
许多开发者都经历过这样的令人沮丧的体验:看到一条错误消息,以为自己知道它的含义以及如何解决它,但在经过几个小时的徒劳调试后才意识到它完全是别的意思。一位受访者解释了他的沮丧之情如下
“通常打印出的抱怨与问题毫无关系,但我可能需要花一个小时才能发现情况并非如此。错误消息令人不安地简短,而且似乎没有努力去猜测用户可能试图做什么,或者[解释他们]做错了什么。” — 具有 10 年以上经验的专业 Go 开发者
我们认为,开发者工具发出的警告和错误应该简短、易于理解且可操作:阅读它们的人应该能够准确地理解哪里出了问题以及他们可以采取哪些措施来解决问题。这无疑是一个很高的标准,在这项调查中,我们进行了一些测量,以了解开发者如何看待 Go 当前的警告和错误消息。
在思考他们最近解决的 Go 错误消息时,受访者告诉我们还有很大的改进空间。只有一小部分人能仅从错误消息中理解问题本身 (54%),更少的人知道下一步该怎么做才能解决问题 (41%)。似乎可以添加少量额外信息就能显著提高这些比例,因为 1/4 的受访者表示他们基本上知道如何解决问题,但需要先看到一个例子。此外,由于 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 年经验的专业 Go 开发者
可以理解的是,工具链错误消息和运行时错误消息之间存在着模糊的概念边界。例如,最常见的请求之一是改进堆栈跟踪或其他方法来帮助调试运行时崩溃 (22%)。同样,4% 的反馈中出现了令人惊讶的主题,即有关从go
命令本身获取帮助的挑战。这些都是 Go 社区帮助我们识别原本没有列在我们雷达上的相关痛点的绝佳示例。我们最初开始调查的重点是改进编译时错误,但 Go 开发者希望看到改进的核心领域之一实际上与运行时错误有关,而另一个则与go
命令的帮助系统有关。
“当抛出错误时,调用堆栈可能很大,并且包含许多我不关心的文件。我只想知道问题出现在我的代码中的哪里,而不是我使用的库,或者恐慌是如何处理的。” — 具有 1-2 年经验的专业 Go 开发者
“通过
go help run
获取帮助会转储一大堆文本,以及指向进一步阅读内容的链接,以找到可用的命令行标志。或者它理解go run –help
,但它没有显示帮助,而是说“请运行 go help run 代替”。只要在go run –help
中向我显示标志列表。” — 具有 3-4 年经验的专业 Go 开发者
微服务
我们经常听到开发者认为 Go 非常适合微服务,但我们从未尝试量化有多少 Go 开发者采用了这种类型的服务架构,了解这些服务是如何相互通信的,以及开发者在处理这些服务时遇到的挑战。今年,我们添加了一些问题以更好地了解这个领域。
大多数受访者表示,他们主要从事微服务 (43%),另有 1/4 的受访者表示,他们既从事微服务,也从事单体应用。只有大约 1/5 的受访者主要从事单体 Go 应用程序。这是为数不多的几个在受访者工作的组织规模方面存在差异的领域之一——大型组织似乎比小型公司更倾向于采用微服务架构。来自大型组织(> 1000 名员工)的受访者最有可能表示他们从事微服务 (55%),只有 11% 的这些受访者主要从事单体应用。
我们看到,构成 Go 平台的微服务数量存在一些分化。一组是由少数(2 到 5 个)服务组成的 (40%),而另一组则是由更大的集合组成的,至少包含 10 个组件服务 (37%)。涉及的微服务数量似乎与组织规模无关。
绝大多数受访者使用某种形式的直接响应请求(例如,RPC、HTTP 等)进行微服务通信 (72%)。一小部分受访者使用消息队列 (14%) 或发布/订阅方法 (9%);同样,我们在组织规模方面没有看到任何差异。
大多数受访者使用多种语言构建微服务,只有大约 1/4 的受访者专门使用 Go。Python 是最常见的配套语言 (33%),其次是 Node.js (28%) 和 Java (26%)。我们再次看到组织规模方面的差异,大型组织更有可能集成 Python (43%) 和 Java (36%) 微服务,而小型组织更有可能只使用 Go (30%)。其他语言似乎在组织规模方面使用率相同。
总的来说,受访者告诉我们,在编写基于微服务的应用程序时,测试和调试是他们面临的最大挑战,其次是操作复杂性。许多其他挑战在这个图表的尾部占据了很长的时间,尽管“可移植性”对于大多数受访者来说是一个非问题。我们将其解释为,此类服务并非旨在实现可移植性(超出基本容器化);例如,如果组织的微服务最初由 PostgreSQL 数据库提供支持,那么开发者不会担心在不久的将来将其移植到 Oracle 数据库。
模块作者和维护
Go 拥有充满活力的社区驱动模块生态系统,我们希望了解维护这些模块的开发人员的动机和面临的挑战。我们发现,大约 1/5 的受访者维护(或曾经维护)过一个开源 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 来扩展他们的技能 (38%) 或评估其在工作中的应用 (13%),而不是经验丰富的 Go 开发者。我们将其解释为许多 Gopher 最初将 Go 视为“提升技能”或扩展他们对软件开发理解的一部分,但在一年或两年内,他们将 Go 视为一种更注重“做”而非“学”的工具。
Go 最常见的用例仍然是 API/RPC 服务 (74%) 和命令行工具 (62%)。人们告诉我们,Go 是这些类型的软件的绝佳选择,原因包括内置的 HTTP 服务器和并发原语、易于交叉编译以及单二进制部署。
这些工具的目标受众大多是商业环境 (62%),17% 的受访者报告称他们主要为面向消费者的应用程序开发。考虑到 Go 在面向消费者的应用程序 (例如桌面、移动或游戏) 中的使用率较低,而在后端服务、CLI 工具和云开发中的使用率非常高,这一点并不令人惊讶,但这确实证实了 Go 在 B2B 环境中得到了广泛应用。
我们还根据受访者使用 Go 的经验水平和组织规模寻找差异。经验丰富的 Go 开发者报告说,他们在 Go 中构建了更多种类的不同事物;这种趋势在每个应用程序或服务的类别中都是一致的。我们没有发现任何根据组织规模在受访者构建内容方面存在显著差异。
受访者在第一次参加 Go 开发者调查和之前参加过调查之间几乎是等概率的。从 Go 博客了解到这份调查的人群与从 VS Code 中的通知中了解到这份调查的人群之间存在显著差异,前者 61% 的人报告之前参加过这份调查,而后者只有 31% 的人说他们之前参加过这份调查。我们不期望人们能够完美地回忆起自己在互联网上填写过的每一项调查,但这让我们更有信心,在每次调查中,我们都收到了来自新受访者和重复受访者的平衡组合。此外,这告诉我们,我们的社交媒体帖子和随机编辑器内采样相结合,对于从各种 Go 开发者那里获得反馈都是必要的。
公司信息
这份调查的受访者报告说他们在各种不同的组织工作,从拥有 1000 多名员工的企业 (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 开发者”。
结语
我们调查中的最后一个问题总是问受访者是否还有其他关于 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 团队)
下一篇文章:使用 deadcode 查找无法访问的函数
上一篇文章:Go 的十四年
博客索引