多么热烈的响应！

我想首先要万分感谢今年有数千名 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 不到两年。多数人还表示他们在工作中使用 Go（72%），工作之外也使用 Go（62%）。专业使用 Go 的受访者比例似乎逐年上升。

正如您在下图中看到的，2018 年这些数字有所增长，但今年的增长消失了。这是许多信号之一，表明 2018 年回答调查的受众与其他三年显著不同。在这种情况下，他们更可能在工作之外使用 Go，而在工作时使用另一种语言，但我们在多个调查问题中都看到了类似的异常值。

使用 Go 时间最长的受访者与新 Go 开发者的背景不同。这些 Go 老兵更倾向于声称精通 C/C++，而不太可能声称精通 JavaScript、TypeScript 和 PHP。一个需要注意的是，这是自我报告的“专业知识”；将其视为“熟悉度”可能更有帮助。Python 是（Go 之外）最受大多数受访者熟悉的语言，无论他们使用 Go 多久。

去年我们询问了受访者所在的行业，发现大多数人表示在软件、互联网或网络服务公司工作。今年，受访者似乎代表了更广泛的行业。然而，我们也简化了行业列表，以减少潜在重叠类别引起的混淆（例如，2018 年的“软件”和“互联网/网络服务”被合并为 2019 年的“科技”）。因此，这并非严格的“苹果对苹果”的比较。例如，简化类别列表的一个影响可能是，将“软件”类别用作一个“万能”类别，以便包含那些为未明确列出的行业编写 Go 软件的受访者。

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. 三大全球云提供商（Amazon Web Services、Google Cloud Platform 和 Microsoft Azure）在受访者中的使用率似乎都在上升，而其他大多数提供商的使用比例每年都在下降。
2. 本地部署到自建或公司拥有的服务器的比例持续下降，现在与 AWS（44% vs 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% 指出泛型是一个关键的缺失功能。对错误处理的持续改进（除了 Go 1.13 的更改）被 22% 的受访者提及，而 13% 的人要求更多函数式编程功能，特别是内置的 map/filter/reduce 功能。需要明确的是，这些数字来自那些表示如果 Go 不缺少一些关键功能，他们就可以更多地使用 Go 的受访者子集，而不是所有调查受访者。

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

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

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

最后，当我们询问什么能最大程度地改善 respondents 的编辑环境中的 Go 支持时，最常见的回复是总体改进或对语言服务器（gopls）的更好支持（19%）。这是意料之中的，因为 gopls 取代了大约 80 个现有工具，并且仍处于 Beta 阶段。当受访者对他们希望看到的改进更具体时，他们最有可能提到调试体验（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 社区中的女性比例。例如，我们知道美国女性软件开发者的回复率约为我们根据美国就业数据预期的一半（11% vs 20%）。由于我们不知道美国受访者的比例，我们无法安全地从这些数字中推断，只能说实际比例可能高于 3%。此外，GDPR 要求我们更改收集敏感信息的方式，这包括性别和传统上代表性不足的群体。不幸的是，这些更改使我们无法将这些数字与往年进行有效比较。

那些认同代表性不足群体或选择不回答该问题的受访者，在“我觉得在 Go 社区中很受欢迎”这一陈述上表现出更高的不同意率（8% vs 4%），这凸显了我们持续的推广工作的重要性。

结论

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