2020-04-20 2019 年 Go 开发者调查结果

:::info 日期：2020 年 04 月 20 日
作者：Todd Kulesza
原文链接：https://go.dev/blog/survey2019-results :::

反馈是什么样的

首先，我要非常感谢参与今年调查的数千名 Go 开发人员。 2019 年，我们看到了 10,975 条回复，几乎是去年的两倍！ 我代表团队的其他成员，无法充分强调我们非常感谢您花时间和精力告诉我们您使用 Go 的经历。 谢谢！

关于年前的一个注记

眼尖的读者可能会注意到，我们的年度比较与我们过去分享的数字并不完全一致。 原因是从 2016 年到 2018 年，我们使用开始调查的总人数作为分母计算每个问题的百分比。 虽然这很好且一致，但它忽略了这样一个事实，即并非每个人都完成了调查——多达 40% 的参与者在到达最后一页之前停下来，这意味着在调查中出现的问题似乎仅仅因为它们出现得更晚而表现更差。 因此，今年我们重新计算了所有结果（包括本文中显示的 2016-2018 年回复），以使用回答给定问题的人数作为该问题的分母。 我们在 x 轴或图表的图例中以“n=[受访者人数]”的形式包含了每个图表的 2019 年回复数量，以便读者更好地了解每个图表背后的证据权重 发现。

同样，我们了解到，在之前的调查中，响应列表中较早出现的选项具有不成比例的响应率。 为了解决这个问题，我们在调查中添加了随机化元素。 我们的一些选择题包含没有逻辑顺序的选项列表，例如“我在 Go 中编写以下内容：[应用程序类型列表]”。 以前这些选择是按字母顺序排列的，但在 2019 年，它们以随机顺序呈现给每个参与者。 这意味着某些问题的同比比较对于 2018 → 2019 是无效的，但 2016-2018 的趋势并未无效。 您可以将其视为为 2019 年设置更准确的基线。如果受访者可能会扫描特定名称（例如他们首选的编辑器），我们保留了字母顺序。 我们在下面明确指出这适用于哪些问题。

第三个主要变化是改进了我们对开放式、自由文本回答问题的分析。 去年，我们使用机器学习粗略但快速地对这些响应进行分类。 今年，两名研究人员手动对这些回答进行了分析和分类，允许进行更精细的分析，但无法与去年的数字进行有效比较。 与上面讨论的随机化一样，此更改的目的是为我们提供 2019 年以后的可靠基线。

言归正传

这是一个很长的帖子。 这是我们主要发现的 tl;dr：

• 我们的受访者的人口统计数据与 Stack Overflow 的调查受访者相似，这增加了我们对这些结果代表更大的 Go 开发人员受众的信心。
• 大多数受访者每天都在使用 Go，而且这个数字每年都在呈上升趋势。
• Go 的使用仍然集中在科技公司，但 Go 越来越多地出现在更广泛的行业中，例如金融和媒体。
• 方法论的变化向我们表明，我们的大部分同比指标都稳定且高于我们之前意识到的。
• 受访者正在使用 Go 解决类似的问题，尤其是构建 API/RPC 服务和 CLI，无论他们工作的组织规模如何。
• 大多数团队尝试快速更新到最新的 Go 版本； 当第三方提供商迟迟不支持当前的 Go 版本时，这会为开发人员带来采用障碍。
• Go 生态系统中的几乎每个人现在都在使用模块，但在包管理方面仍然存在一些困惑。
• 需要改进的高优先级领域包括改进开发人员的调试体验、使用模块和使用云服务。
• VS Code 和 GoLand 的使用量继续增加； 他们现在受到四分之三的受访者的青睐。

我们是从谁那里了解到 Go?

今年，我们提出了一些新的人口统计问题，以帮助我们更好地了解对本次调查做出回应的人。 我们特别询问了专业编程经验的持续时间以及人们工作的组织的规模。 这些都是以 StackOverflow 在其年度调查中提出的问题为模型的，我们看到的回答分布非常接近 StackOverflow 2019 年的结果。 我们的结论是，本次调查的受访者与 StackOverflow 的调查对象具有相似的专业经验水平和不同规模组织的比例代表（明显的区别是我们主要从使用 Go 的开发人员那里听到的）。 当将这些发现推广到全球估计的 100 万 Go 开发人员时，这增加了我们的信心。 这些人口统计问题还将帮助我们在未来确定哪些同比变化可能是响应调查的人发生变化，而不是情绪或行为变化的结果。


从 Go 体验来看，我们发现大多数受访者 (56%) 对 Go 相对较新，使用时间不到两年。 大多数人还表示，他们在工作中 (72%) 和工作之外 (62%) 使用 Go。 专业使用围棋的受访者百分比似乎每年都在上升。 如下图所示，2018 年我们看到这些数字激增，但今年这种增长消失了。 这是表明 2018 年回答调查的受众与其他三年显着不同的众多信号之一。 在这种情况下，他们更有可能在工作之外使用 Go 并在工作中使用不同的语言，但我们在多个调查问题中看到了类似的异常值。


使用 Go 时间最长的受访者与新的 Go 开发人员有着不同的背景。 这些 Go 老手更有可能声称拥有 C/C++ 方面的专业知识，而不太可能声称拥有 JavaScript、TypeScript 和 PHP 方面的专业知识。 一个警告是，这是自我报告的“专业知识”； 将其视为“熟悉”可能会更有帮助。 Python 似乎是大多数受访者熟悉的语言（除了 Go），无论他们使用 Go 多长时间。

去年，我们询问了受访者在哪些行业工作，发现大多数报告在软件、互联网或网络服务公司工作。 今年看来，受访者代表了更广泛的行业。 但是，我们也简化了行业列表，以减少潜在重叠类别造成的混淆（例如，2018 年将“软件”和“互联网/网络服务”的单独类别合并为 2019 年的“技术”）。 因此，这并不是严格意义上的苹果对苹果的比较。 例如，简化类别列表的一个效果可能是减少“软件”类别的使用，作为为未明确列出的行业编写 Go 软件的受访者的统称。

Go 是一个成功的开源项目，但这并不意味着使用它的开发人员也在编写免费或开源软件。 与前几年一样，我们发现大多数受访者并不是 Go 开源项目的频繁贡献者，75% 的人表示他们“很少”或“从不”这样做。 随着 Go 社区的扩大，我们看到从未为 Go 开源项目做出贡献的受访者比例正在缓慢上升。

开发者工具

与前几年一样，绝大多数受访者表示在 Linux 和 macOS 系统上使用 Go。 这是我们的受访者与 StackOverflow 2019 年结果之间存在很大分歧的一个领域：在我们的调查中，只有 20% 的受访者使用 Windows 作为主要开发平台，而对于 StackOverflow，这一比例为 45%。 Linux 的使用率为 66%，macOS 为 53%——均远高于 StackOverflow 的受众，后者分别报告了 25% 和 30%。


编辑合并的趋势今年仍在继续。 GoLand 今年的使用量增幅最大，从 24% → 34%。 VS Code 的增长放缓，但它仍然是受访者中最受欢迎的编辑器，占 41%。 综合起来，这两位编辑现在受到四分之三的受访者的青睐。

其他所有编辑都看到了小幅下降。 这并不意味着这些编辑器根本没有被使用，但他们并不是受访者所说的他们更喜欢使用的编写 Go 代码的工具。

今年我们增加了一个关于内部 Go 文档工具的问题，比如 gddo。 少数受访者 (6%) 表示他们的组织运行自己的 Go 文档服务器，但当我们查看大型组织（至少拥有 5,000 名员工）的受访者时，这一比例几乎翻了一番（达到 11%）。 对表示其组织已停止运行自己的文档服务器的受访者进行的后续调查表明，停用服务器的主要原因是感知收益低 (23%) 与最初设置它所需的工作量和 保持它（38%）。

对 Go 的满意程度

大部分受访者同意 Go 对他们的团队运行良好（86%），并且他们更愿意在下一个项目中使用它（89%）。 我们还发现，超过一半的受访者 (59%) 认为 Go 对其公司的成功至关重要。 自 2016 年以来，所有这些指标都保持稳定。

标准化结果改变了前几年的大部分数字。 例如，同意“围棋对我的团队来说效果很好”这一说法的受访者比例在 50 年代和 60 年代之前是因为参与者的流失； 当我们删除从未见过这个问题的参与者时，我们发现它自 2016 年以来一直相当稳定。

看看围棋生态系统中解决问题的情绪，我们看到了类似的结果。 大部分受访者同意每个陈述 (82%–88%)，并且这些比率在过去四年中基本保持稳定。

今年，我们对各行各业的满意度进行了更细致的研究，以建立基线。 总体而言，无论哪个行业，受访者都对在工作中使用 Go 持积极态度。 我们确实在一些领域看到了不满意的微小变化，最显着的是制造业，我们计划通过后续研究进行调查。 同样，我们询问了对 Go 开发各个方面的满意度和重要性。 将这些措施组合在一起突出了三个特别关注的主题：调试（包括调试并发）、使用模块和使用云服务。 这些主题中的每一个都被大多数受访者评为“非常”或“非常重要”，但与其他主题相比，满意度得分明显较低。


谈到对 Go 社区的看法，我们看到了与前几年的一些差异。 首先，同意“我在 Go 社区感到受欢迎”这一说法的受访者比例从 82% 下降到 75%。 深入挖掘发现，“比较同意”或“比较同意”的受访者比例有所下降，而“既不同意也不反对”和“非常同意”的比例均有所上升（分别上升了5个百分点和7个百分点）。 这种两极分化的分裂表明，在 Go 社区中的经历存在分歧的两个或更多群体，因此是我们计划进一步调查的另一个领域。

其他重大差异是对“我很高兴为 Go 项目做出贡献”这一声明的回应呈明显上升趋势，并且认为 Go 的项目领导了解他们需求的受访者比例同比大幅增加。

所有这些结果都表明，从大约两年开始，更高的一致性模式与围棋经验的增加相关。 换句话说，受访者使用 Go 的时间越长，他们就越有可能同意这些陈述中的每一个。

这可能不足为奇，但对 Go 开发者调查做出回应的人往往喜欢 Go。 但是，我们还想了解受访者喜欢使用哪些其他语言。 这些数字中的大部分与前几年相比没有显着变化，只有两个例外：TypeScript（增加了 10 分）和 Rust（增加了 7 分）。 当我们按 Go 经验的持续时间分解这些结果时，我们看到了与语言专业知识相同的模式。 特别是，Python 是 Go 开发人员最有可能喜欢使用的语言和生态系统。

2018 年，我们首次提出了“您会推荐……”净推荐值 (NPS) 问题，得到 61 分。今年我们的 NPS 结果在统计上保持不变，为 60（67% 的“推荐者”减去 7% 的“批评者”）。

使用 Go 工作

构建 API/RPC 服务 (71%) 和 CLI (62%) 仍然是 Go 最常见的用途。 下图似乎显示了 2018 年以来的重大变化，但这些很可能是随机选择顺序的结果，以前按字母顺序列出：4 个以“A”开头的选项中的 3 个减少了，而其他一切都保持稳定或 增加。 因此，最好将此图表解释为 2019 年更准确的基线，其中包含 2016-2018 年的趋势。 例如，我们认为构建返回 HTML 的 Web 服务的受访者比例自 2016 年以来一直在下降，但可能被低估了，因为此响应始终位于一长串选择的底部。 我们还按组织规模和行业划分了这一点，但没有发现显着差异：无论是在小型科技初创企业还是大型零售企业工作，受访者似乎都以大致相似的方式使用 Go。

一个相关问题询问了受访者使用 Go 的更大领域。 迄今为止，最常见的领域是 Web 开发 (66%)，但其他常见领域包括数据库 (45%)、网络编程 (42%)、系统编程 (38%) 和 DevOps 任务 (37%)。


除了受访者正在构建的内容之外，我们还询问了他们使用的一些开发技术。 大多数受访者表示他们依赖文本日志进行调试 (88%)，他们的自由文本回应表明这是因为替代工具难以有效使用。 然而，本地逐步调试（例如，使用 Delve）、分析和使用竞争检测器进行测试并不少见，大约 50% 的受访者依赖于这些技术中的至少一种。

关于包管理，我们发现绝大多数受访者都采用了 Go 模块（89%）。 这对开发人员来说是一个巨大的转变，几乎整个社区似乎都在同时经历它。

我们还发现，75% 的受访者评估当前的 Go 版本是否用于生产，另有 12% 的受访者在等待一个发布周期。 这表明绝大多数 Go 开发人员正在使用（或至少尝试使用）当前或以前的稳定版本，突出了平台即服务提供商快速支持 Go 新稳定版本的重要性。

Go 在云上的使用

Go 的设计考虑了现代分布式计算，我们希望继续改进使用 Go 构建云服务的开发人员体验。 今年，我们扩展了有关云开发的问题，以更好地了解受访者如何与云提供商合作、他们喜欢当前的开发人员体验以及可以改进的地方。 如前所述，2018 年的一些结果似乎是异常值，例如自有服务器的结果出乎意料地低，而 GCP 部署的结果出乎意料地高。

我们看到两个明显的趋势：

1. 全球三大云供应商（亚马逊网络服务、谷歌云平台和微软 Azure）在调查受访者中的使用率似乎都呈上升趋势，而大多数其他供应商每年使用的受访者比例较小
2. 到自有或公司自有服务器的本地部署继续减少，现在统计上与 AWS（44% 对 42%）联系在一起，成为最常见的部署目标。

查看受访者使用的云平台类型，我们发现主要提供商之间存在差异。 部署到 AWS 和 Azure 的受访者最有可能直接使用虚拟机（分别为 65% 和 51%），而部署到 GCP 的受访者使用托管 Kubernetes 平台（GKE，64%）的可能性几乎是虚拟机的两倍（ 35%）。 我们还发现，部署到 AWS 的受访者使用托管 Kubernetes 平台（32%）和使用托管无服务器平台（AWS Lambda，33%）的可能性相同。 GCP (17%) 和 Azure (7%) 使用无服务器平台的受访者比例较低，自由文本回复表明主要原因是延迟支持这些平台上的最新 Go 运行时。 总体而言，大多数受访者对在所有三个主要云提供商上使用 Go 感到满意。 受访者对 AWS（80% 满意）和 GCP（78%）的 Go 开发表示了相似的满意度。 Azure 的满意度得分较低（57% 满意），自由文本回复表明主要驱动因素是认为 Go 在该平台上缺乏一流的支持（25% 的自由文本回复）。 在这里，“一流的支持”是指始终与最新的 Go 版本保持同步，并确保 Go 开发人员在发布时可以使用新功能。 这与使用 GCP 的受访者 (14%) 报告的最大痛点相同，并且特别关注在无服务器部署中支持最新的 Go 运行时。 相比之下，部署到 AWS 的受访者最有可能表示 SDK 可以进行改进，例如更加惯用 (21%)。 SDK 改进也是 GCP (9%) 和 Azure (18%) 开发人员的第二个最常见要求。

痛点

受访者表示他们无法更多地使用 Go 的主要原因仍然是在用另一种语言的项目上工作 (56%)，在一个更喜欢使用另一种语言的团队中工作 (37%)，以及 Go 本身缺乏关键功能 (25%)。

这是我们随机选择列表的问题之一，因此尽管 2016-2018 年的趋势是有效的，但逐年比较是无效的。 例如，我们相信由于团队更喜欢不同的语言而无法更频繁地使用 Go 的开发人员的数量每年都在减少，但我们不知道今年的减少是急剧加速，还是总是略低于 我们估计 2016-2018 年的数字。

前两个采用阻碍者（在现有的非 Go 项目上工作并在更喜欢不同语言的团队中工作）没有直接的技术解决方案，但其余的阻碍者可能。 因此，今年我们询问了更多细节，以更好地了解我们如何帮助开发人员增加他们对 Go 的使用。 本节其余部分的图表基于手动分类的自由文本响应，因此它们有很长的尾巴； 对于每个图表，总回答少于 3% 的类别被归入“其他”类别。 单个回复可能会提及多个主题，因此图表的总和不会达到 100%。

在表示 Go 缺少他们需要的语言功能的 25% 的受访者中，79% 的人指出泛型是一个关键的缺失功能。 22% 的人提到了对错误处理的持续改进（除了 Go 1.13 的更改），而 13% 的人要求更多的函数式编程特性，特别是内置的 map/filter/reduce 功能。 需要明确的是，这些数字来自一部分受访者，他们表示如果没有遗漏他们需要的一个或多个关键功能，他们将能够更多地使用 Go，而不是整个调查受访者群体。

对于他们的工作而言，认为 Go “不是一种合适的语言”的受访者有各种各样的原因和用例。 最常见的是他们从事某种形式的前端开发 (22%)，例如用于 Web、桌面或移动设备的 GUI。 另一个常见的回应是，受访者表示他们在一个已经占主导地位的语言 (9%) 的领域工作，这使得使用不同的东西成为一项挑战。 一些受访者还告诉我们他们指的是哪个领域（或者只是提到了一个领域，而没有提到更常见的另一种语言），我们通过下面的“我在 [领域] 工作”行显示了这一点。 受访者引用的另一个首要原因是需要更好的性能 (9%)，尤其是实时计算。

受访者报告的最大挑战与去年基本一致。 Go 缺乏泛型和模块/包管理仍然位居榜首（分别占回答的 15% 和 12%），并且强调工具问题的受访者比例增加。 这些数字与上面的图表不同，因为这个问题是向所有受访者提出的，无论他们说他们最大的 Go 采用障碍是什么。 所有这三个领域都是 Go 团队今年的重点领域，我们希望在未来几个月内极大地改善开发人员体验，尤其是在模块、工具和入门体验方面。

诊断故障和性能问题在任何语言中都具有挑战性。 受访者告诉我们，他们面临的最大挑战不是 Go 的实现或工具，而是一个更基本的问题：自我报告缺乏知识、经验或最佳实践。 我们希望在今年晚些时候通过文档和其他教育材料帮助解决这些知识差距。 其他主要问题确实涉及工具，特别是学习/使用 Go 的调试和分析工具的不利成本/收益权衡，以及使工具在各种环境中工作的挑战（例如，在容器中调试，或从生产中获取性能配置文件） 系统）。


最后，当我们询问受访者编辑环境中什么最能改进 Go 支持时，最常见的回答是一般改进或对语言服务器的更好支持（gopls，19%）。 这是意料之中的，因为 gopls 替换了大约 80 个现存的工具，并且仍处于测试阶段。 当受访者更具体地说明他们希望看到哪些改进时，他们最有可能报告调试体验 (14%) 和更快或更可靠的代码完成 (13%)。 一些参与者还明确提到在使用 gopls 时需要频繁重启 VS Code（8%）； 自从本次调查进入现场以来（2019 年 11 月下旬至 12 月上旬），这些 gopl 的许多改进已经落地，这仍然是团队的高度优先领域。

Go 社区

大约三分之二的受访者使用 Stack Overflow 来回答他们与 Go 相关的问题（64%）。 其他排名靠前的答案来源是 godoc.org（47%）、直接阅读源代码（42%）和 golang.org（33%）。

上图中的长尾突出了受访者在使用 Go 进行开发时克服挑战所依赖的大量不同来源（几乎都是社区驱动的）和模式。 事实上，对于许多 Gopher 来说，这可能是他们与更大社区互动的主要点之一：随着我们社区的扩大，我们看到越来越多的受访者不参加任何与 Go 相关的活动。 2019 年，这一比例接近三分之二的受访者 (62%)。

由于更新了谷歌范围的隐私指南，我们不能再询问受访者居住在哪些国家。相反，我们询问了首选的口语/书面语言，作为 Go 在全球范围内使用的一个非常粗略的代理，其好处是为潜在的本地化工作提供数据 .

由于这项调查是用英语进行的，因此很可能对说英语的人和来自英语为第二或第三语言的地区的人有很大的偏见。 因此，非英语数字应被解释为可能的最小值，而不是围棋全球受众的近似值。

我们发现 12% 的受访者认同传统上代表性不足的群体（例如种族、性别认同等），3% 认同女性。 （这个问题应该说“女性”而不是“女性”。这个错误已经在我们 2020 年的调查草案中得到纠正，我们对此表示歉意。）我们强烈怀疑这 3% 的人低估了 Go 社区中的女性。 例如，我们知道美国的女性软件开发人员对 StackOverflow 开发人员调查的回应率约为我们根据美国就业数据预期的一半（11% 对 20%）。 由于我们不知道美国的回应比例，因此除了说实际比例可能高于 3% 之外，我们不能安全地从这些数字中推断出来。 此外，GDPR 要求我们改变询问敏感信息的方式，其中包括性别和传统上代表性不足的群体。 不幸的是，这些变化使我们无法将这些数字与前几年进行有效比较。

与不认同弱势群体的受访者相比，认同弱势群体或不愿回答此问题的受访者对“我在 Go 社区感到受欢迎”这一陈述的异议率更高（8% 对 4%），突出显示 我们持续开展外联工作的重要性。

总结

我们希望您喜欢看到我们 2019 年开发者调查的结果。 了解开发人员的经验和挑战有助于我们规划 2020 年的工作并确定其优先级。再次非常感谢为本调查做出贡献的所有人——您的反馈有助于引导 Go 在未来一年及以后的发展方向。