Go 博客

Go 开发者调查 2019 结果

Todd Kulesza
2020 年 4 月 20 日

多么热烈的反响！

我要首先向今年参与调查的数千名 Go 开发者表示衷心的感谢。在 2019 年，我们收到了 10,975 份回复，几乎是去年的两倍！我代表团队的其他成员，无法充分表达我们对您抽出时间和精力告诉我们您使用 Go 的体验的感谢。谢谢您！

关于往年的说明

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

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

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

事不宜迟…

这是一篇长文。以下是我们主要发现的简要总结

• 我们回复者的构成与 Stack Overflow 调查回复者类似，这增强了我们对这些结果代表更广泛的 Go 开发者群体的信心。
• 大多数回复者每天使用 Go，而且这个数字每年都在增长。
• Go 的使用仍然集中在科技公司，但 Go 越来越广泛地出现在其他行业，例如金融和媒体。
• 方法论的变化表明，我们大多数逐年指标都保持稳定，并且高于我们之前的认识。
• 无论组织规模大小，回复者都使用 Go 来解决类似的问题，特别是构建 API/RPC 服务和 CLI。
• 大多数团队试图快速更新到最新的 Go 版本；当第三方提供商迟迟不支持当前 Go 版本时，这会为开发人员创建采用障碍。
• 现在，几乎所有 Go 生态系统中的每个人都在使用模块，但围绕包管理的一些困惑仍然存在。
• 改进的优先领域包括改进调试、使用模块以及使用云服务的开发人员体验。
• VS Code 和 GoLand 继续看到使用量增加；它们现在被 4 个回复者中的 3 个使用。

我们从谁那里听到了声音？

今年，我们提出了一些新的关于人口统计的问题，以帮助我们更好地了解回复过本次调查的人员。我们特别询问了专业编程经验的持续时间以及人们工作的组织规模。这些问题是根据 StackOverflow 在其年度调查中提出的问题进行建模的，我们看到的回复分布与 StackOverflow 的 2019 年结果非常接近。我们的结论是，本次调查的回复者拥有与 StackOverflow 调查受众类似的专业经验水平和不同组织规模的比例代表性（显而易见的区别是我们主要从使用 Go 的开发人员那里获得反馈）。这增强了我们在将这些发现推广到全球估计的 100 万 Go 开发人员时所持的信心。这些人口统计问题还将在将来帮助我们识别哪些逐年变化可能是调查回复者变化的结果，而不是观点或行为的变化。

从 Go 经验来看，我们发现大多数回复者（56%）对 Go 相对陌生，使用时间不超过两年。大多数回复者还表示他们在工作中（72%）和工作之外（62%）使用 Go。在工作中使用 Go 的回复者比例似乎每年都在增长。

正如您在下面的图表中看到的，在 2018 年，我们看到这些数字出现了激增，但这种增长在今年消失了。这是许多迹象中的一个，表明 2018 年回答调查问卷的受众与其他三年中不同。在这种情况下，他们更有可能在工作之外使用 Go 以及在工作中使用其他语言，但我们在多个调查问题中看到了类似的异常值。

使用 Go 时间最长的回复者具有与 Go 新手不同的背景。这些 Go 老手更有可能声称精通 C/C++，而不太可能声称精通 JavaScript、TypeScript 和 PHP。一个需要注意的是，这是自我报告的“精通程度”；将其视为“熟悉程度”可能更有帮助。无论使用 Go 多长时间，Python 似乎是除 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%。这两款编辑器加起来，现在被 4 个回复者中的 3 个使用。

其他每款编辑器的使用量都有所下降。这并不意味着这些编辑器根本没有被使用，而是说回复者不会将它们作为编写 Go 代码的首选工具。

今年，我们添加了一个关于内部 Go 文档工具（例如gddo）的问题。只有少数回复者（6%）报告他们的组织运行自己的 Go 文档服务器，虽然当我们查看大型组织的回复者（至少有 5,000 名员工）时，这一比例几乎翻了一番（达到 11%）。对那些表示他们的组织已停止运行自己的文档服务器的回复者的后续调查表明，退休服务器的主要原因是感知到的好处较低（23%）与最初设置和维护它所需的努力量（38%）的结合。

对 Go 的看法

绝大多数回复者都同意 Go 对他们的团队非常有效（86%），他们希望在他们的下一个项目中使用 Go（89%）。我们还发现，超过一半的回复者（59%）认为 Go 对他们公司的成功至关重要。所有这些指标自 2016 年以来一直保持稳定。

结果的标准化改变了往年的多数数字。例如，同意“Go 对我的团队非常有效”这一说法的回复者比例之前在 50 年代和 60 年代，因为参与者中途退出；当我们移除从未见过该问题的参与者时，我们发现该指标自 2016 年以来一直相当稳定。

观察 Go 生态系统中对问题解决的态度，我们看到了相似的结果。很大比例的受访者同意每项陈述（82%–88%），并且这些比例在过去四年中基本保持稳定。

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

转向对 Go 社区的看法，我们发现与前几年相比有一些差异。首先，同意“我感觉在 Go 社区中受到欢迎”这一陈述的受访者比例下降了，从 82% 降至 75%。更深入的调查显示，那些“略微同意”或“中等程度同意”的受访者比例下降，而那些“既不同意也不反对”和“强烈同意”的受访者比例均有所上升（分别上升 5 个百分点和 7 个百分点）。这种两极分化的结果表明，存在两个或多个群体在 Go 社区中的体验正在发生分化，因此这是我们计划进一步调查的另一个领域。

其他重大差异是“我感觉可以为 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 年以来发生了重大变化，但这些变化很可能是由于随机化了选项顺序的结果，这些选项以前按字母顺序排列：以“A”开头的 4 个选项中有 3 个下降，而其他所有选项保持稳定或上升。因此，该图表最好被解释为 2019 年的更准确基线，并带有 2016 年至 2018 年的趋势。例如，我们认为，自 2016 年以来，构建返回 HTML 的 Web 服务的受访者比例一直在下降，但很可能被低估了，因为此回复始终位于一个很长的选项列表的底部。我们还根据组织规模和行业对这一点进行了细分，但没有发现显著差异：无论受访者是在小型科技初创企业还是大型零售企业工作，他们似乎都在以大致相同的方式使用 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%。

在 25% 表示 Go 缺乏他们需要的语言功能的受访者中，79% 指出泛型是缺少的关键功能。22% 的人提到了对错误处理的持续改进（除了 Go 1.13 中的变化），而 13% 的人要求更多函数式编程功能，特别是内置的 map/filter/reduce 功能。需要明确的是，这些数字来自表示如果 Go 不缺少他们需要的某些关键功能，他们就能更多地使用 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 月初），许多这些 gopls 改进已经完成，并且这仍然是团队的一个高度优先的领域。

Go 社区

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

上一张图表上的长尾线突出显示了受访者为克服使用 Go 进行开发过程中的挑战而依赖的各种不同来源（几乎所有来源都是社区驱动的）和方式。实际上，对于许多 Gophers 来说，这可能是他们与更广泛社区的主要互动方式之一：随着我们社区的扩大，我们看到越来越多的受访者没有参加任何与 Go 相关的活动。2019 年，这一比例接近受访者的三分之二（62%）。

由于更新的 Google 范围内的隐私准则，我们不再能询问受访者居住的国家/地区。相反，我们询问了他们偏爱的口头/书面语言，这是一种非常粗略的 Go 在全球范围内使用情况的替代指标，它具有为潜在的本地化工作提供数据的优势。

由于这份调查是用英语进行的，因此可能存在明显的偏向英语使用者和来自英语作为常用第二或第三语言的地区的使用者。因此，非英语数字应被解释为可能的最小值，而不是对 Go 全球受众的近似值。

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

与弱势群体认同或选择不回答此问题的受访者，在“我感觉自己受到 Go 社区的欢迎”这一说法上，表示不同意的比例（8% 对比 4%）高于那些不与弱势群体认同的人，这突出了我们持续进行外联工作的重要性。

结论

我们希望您能乐于看到我们 2019 年开发者调查的结果。了解开发者的体验和挑战有助于我们为 2020 年规划和优先排序工作。再次衷心感谢所有参与这份调查的人，您的反馈意见正在帮助引导 Go 在未来一年及更长时间内的发展方向。