Go 调研结果：企业采用率稳步上升，内置工具受青睐 | 2022 开发者生态系统现状
引入
每年，JetBrains 都会向世界各地成千上万的开发者询问有关编程语言使用的问题，并随后公开我们的调研结果。
上个月，我们发布了《2022 开发者生态系统现状》报告。在这篇博文中，我们将深入报告中有关 Go 语言的部分，一起探讨 Go 社区的趋势。
我们邀请了三位社区成员帮助我们分析结果：
Bartlomiej Plotka
Prometheus 维护者
“Efficient Go” 作者
Carolyn Van Slyck
Porter 维护者
运营 Women Who Go
Michael Gasch
AWS EventBridge 产品经理
Go 显然是可用于生产的语言。许多大公司都在生产中使用 Go，而且这个名单每年都在延长。
根据 JetBrains 的研究，在工作相关项目中使用 Go 的开发者比例从 61% 增长到 64%。
开发者生态系统数据与 Go 团队发起的调查较为一致。他们的数据显示，在工作中从事 gopher 编程的比例从 2016 年的 66% 增加到 2021 年的 78%（Go 团队使用多项选择题衡量这一指标）。
很高兴看到 Go 在生产系统中的使用越来越多！它表明了人们对语言的信任，以及更高的采用率。
很高兴看到 Go 在工作中得到越来越多的采用，特别是在企业中！这也意味着语言及其生态系统收获了更多信任。Go 团队和 Sigstore 等社区以及 Cloud Native Computing Foundation 正在为安全性（供应链）、可用性（工具）和一致性（轻松阅读/采用代码库）树立更高标准，这让我非常兴奋。可以肯定的是，随着 Go 取代企业和 ISV/云空间中的更多遗留代码库，我们会在未来几年看到这个数字进一步上升。
模块的概念 – Go 的依赖项管理系统 – 出现在 2018 年年中。1.11 版本添加了对模块的初步支持。
最新数据显示，87% 的 Go 开发者使用模块作为依赖项管理系统。
看到大约 10% 的开发者还在使用大体上已被弃用的软件包管理器，我有点惊讶。我猜这是因为在旧的代码库/项目或工作项目中，工具无法轻易更改。
很高兴看到大多数用户使用快速成为标准的 Go 模块。对于尚未使用它的用户，我建议尽快切换，因为有许多创新是以 Go 模块为基础，例如高级安全或许可证扫描仪、可靠的工具安装等。查看这篇精彩指南更好地理解 Go 模块。
Go 中的 vendoring 是指为特定项目所需的所有依赖项制作自己的本地副本，并将此副本包含在文件树中。这种方法有它的优点 – 使用 vendoring 时，项目将拥有构建应用所需的所有代码。每次构建项目，得到的都是完全相同的二进制文件。因此，您不必从外部源下载依赖项。但 vendoring 也有缺点。
使用 vendoring 的开发者比例从 46% 下降到 41%。
很高兴看到 vendoring 不那么受欢迎了。它会混淆源代码仓库，使建议的代码更改难以审查。它还使开发者在构建确保依赖项缓存和可靠性的专用解决方案时更加懒惰。在某种程度上，Go 模块的普及让开发者可以摆脱 vendoring，因为 Go 模块带来的可靠性和封闭构建，这要归功于 Go 代理和 go.sum 等其他机制。
我认为 Go 模块及其分发、管理和验证软件包的方式（但要注意 TOFU）将进一步减少对 vendor Go 项目的需求。
依赖项被许多开发者视为必要之恶。说它是必要的，是因为没有第三方软件包，就无法构建一个独特的现代应用。说它是邪恶的，是因为技术总在变化，大量依赖项会威胁到项目的稳定性。
只有五分之一的 Go 开发者在项目中有少于 5 个依赖项。
我很喜欢的一点是，Go 会更新go.mod格式来包含直接和间接依赖项。我起初以为自己的依赖项数量完全正常，后来才发现实际数量有 4 倍多！
仔细管理和验证依赖项对每位开发者以及安全、运营和其他团队来说都是一个巨大的负担。感谢 Go 核心团队和 Sigstore 社区让我们处于最佳位置，将供应链管理的复杂性转移到平台/工具上，而不是留给压力巨大的开发者。
人们常说 Go 的向后兼容很棒，但似乎并不是每个人都能使用最新版本。同时使用多个版本的开发者比例从 23% 增加到 32%。
Go 社区和 Google Go 团队每年发布两次次要版本以及许多补丁，以不断改进 Go。随着采用率的提高，总会有一些项目无法赶上最新版本的 Go。
虽然 1.x.0 Go 版本非常可靠，但我通常还是会立即将项目迁移到新版本。然而，对于专业用途，我将 CI 设置为至少运行 2 个（通常是 3 个）不同的版本，检测贡献者何时引入新的语言功能并捕捉其他回归 – 性能、依赖项等。所以我实际上属于两个阵营：本地开发只有一个版本，CI 则有多个。
JavaScript、Python 和 TypeScript 是在单个项目中与 Go 一起使用的最流行的语言。
最初看到 TypeScript 的份额如此之高，我有点惊讶。但我猜 – 完全基于我自己的经验 – 只要体验到像 Go 这样的类型安全和静态编译语言的乐趣，大多数 Go 和其他开发者都会使用 TypeScript 而不是 JavaScript。所以我想，我们会看到这个数字在未来几年继续上升。
由于 Go 大量用于构建端到端解决方案，看到 60% 的用户使用 JavaScript 和 TypeScript 等前端语言并不让人感到意外。由于单仓库很流行，将其他语言混合到单个项目中并不少见。结果表明，超过 40% 是在某种单仓库风格的项目上工作。
在 Web 开发方面，Go 以其出色的标准库而闻名。有时，来自其他语言的开发者会在 Reddit 上询问应该使用什么 Web 框架，答案通常是“使用标准库”或者“构建自己的框架”。
尽管如此，还是有很多人更喜欢使用像 Gin 这样的现成框架。在过去的一年里，Gin 的受欢迎程度从 40% 上升到 46%。
去年的调查没有将“net/http”作为答案选项，这显然导致许多仅使用标准库的用户选择了“无”。我们今年添加后，net/http几乎和 Gin 一样流行。
Go 优秀的标准库足以应对大多数情况。44% 的受访者使用net/http就证实了这一点。这很好，因为这意味着标准库经过了实战考验，也确保辅助库和帮助程序主要集中在 net/http 上，使 Go 更容易被采用。
Go 中的内置测试支持得到许多开发者的赞赏，但此外也有一些框架。最受欢迎的是testify和gomock。
尽管内置工具的数量有所下降，但看到内置工具成为 Go 开发者的标准还是让我相当自豪。对于不同的项目或语言，我经常发现学习工具比学习语言本身更难，因为这里似乎没有标准，特别是对于“旧”语言。Google 搜索通常会显示三种或更多不同的方式，代码库也不例外。这就是我格外喜欢 Go 的原因：强大的测试工具、go fmt等内置工具带来的一致性和更少的歧义！
涉及测试库时，用户选择差异似乎更大。这表明标准库在这方面仍有改进的空间。我的建议是继续使用更简单的框架，例如我们在 Prometheus 生态系统中使用的testutil。测试框架 API 越臃肿和复杂，读取、写入和依赖单元测试就越困难。这意味着开发者拒绝编写更多测试，导致代码更不可靠！
曾经有一段时间，go get命令会直接从 GitHub 等 VCS 系统中的源代码仓库下载模块。这种方式有一些缺点 – 模块可以被其作者删除，版本可以被编辑（您可以在这里和这里详细了解旧方式的优缺点）。
2019 年，Go 团队推出了缓存模块的公共代理服务器。从 1.13 版本开始，GOPROXY的默认值为https://proxy.golang.org,direct。proxy.golang.org服务器是所有 Go 开发者都可以访问的公共仓库，它在启动go get命令时为模块提供服务。这种方式可以确保您需要的模块始终可用。
根据 JetBrains 调查，51% 的受访者不使用代理。 如 Carolyn Van Slyck 在她的评论中所说，一些开发者可能不知道GOPROXY的默认值。在新的调查中，我们会尽量考虑到这一点。
我很惊讶有这么多人不使用代理！我怀疑许多 gopher 没有意识到 Go 代理默认启用，实际上并没有明确关闭GOPROXY。
Go 的内置模板软件包text/template和html/template是生成文本和 HTML 输出的绝佳方式。我们的研究表明，Go 开发者还使用 Pongo2（类似 Django 语法的模板引擎）和 Plush。
随着 Go 采用率的增加，我们希望看到更多应用程序使用模板引擎渲染网站以外的工件（例如配置）。记住，渲染 HTML 页面时，请始终使用text/template，因为它会清理输入以避免代码注入攻击。
gopls 是 Go 团队开发的官方 Go 语言服务器 (LSP)。GoLand 与其他 JetBrains IDE 一样，使用不同于 LSP 的方式构建自己的源代码内部表示。
这个问题向不使用 GoLand 的受访者显示。结果表明，其中 61% 使用gopls。
我们还询问了gopls用户的满意度。
gopls每天都在改进，但还不完美，所以我并不惊讶用户希望看到更多改进。我个人还是更喜欢用 GoLand 完成所有软件开发工作，因为它有更丰富的导航、搜索和重构功能。
过去几年，gopls绝对变得更好了。我记得，有好几次我必须不断重启语言服务器或编辑器，因为语法高亮显示和其他功能出了问题。但与 GoLand 相比，特别是重构和智能类型匹配补全的强大功能，我认为gopls还有很长的路要走。但我明白，如果你不是每天/专业地编写 Go 代码，这些功能也可能稍显多余。
查看完整报告
本博文英文原作者：Sergey Kozlovskiy
相关阅读：历年开发者生态系统现状报告
⏬ 戳「阅读原文」查看完整版调研报告