Go 博客
Go 开发者调查 2019 结果
热烈的回应!
我想首先对参与今年调查的数千名 Go 开发者表示巨大的 感谢。2019 年,我们收到了 10,975 份回复,几乎是 去年的两倍!我代表团队其他成员,无论如何也无法充分表达我们对您抽出时间和精力告诉我们您使用 Go 体验的感激之情。谢谢!
关于往年的说明
细心的读者可能会注意到,我们的同比比较数据与我们过去分享的数据不完全吻合。原因在于,从 2016 年到 2018 年,我们计算每个问题的百分比时,使用了开始调查的总人数作为分母。虽然这很一致,但忽略了并非所有人都完成调查的事实——高达 40% 的参与者在到达最后一页之前就停止了,这意味着调查后期出现的问题表现得更差,仅仅是因为它们靠后。因此,今年我们重新计算了所有结果(包括本文中显示的 2016-2018 年回复),使用回答特定问题的人数作为该问题的分母。我们在每张图表中都包含了 2019 年的回复数量——以“n=[回复人数]”的形式显示在 x 轴或图表的图例中——以便读者更好地理解每个发现的证据权重。
同样地,我们了解到在先前的调查中,回复列表中靠前的选项回复率不成比例地高。为了解决这个问题,我们在调查中添加了随机化元素。我们的一些多项选择题的选项列表没有逻辑顺序,例如“我在 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 的使用量持续增加;现在它们受到四分之三的受访者的青睐。
我们从谁那里听取了意见?
今年我们询问了一些新的人口统计问题,以帮助我们更好地了解回复本次调查的人群。特别是,我们询问了专业编程经验时长以及人们工作组织的规模。这些问题模仿了 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。需要注意的是,这是自我报告的“精通”;将其视为“熟悉”可能更有帮助。Python 似乎是大多数受访者熟悉(除 Go 之外)的语言,无论他们使用 Go 多久。
去年我们询问了受访者所在的行业,发现大多数人报告在软件、互联网或网络服务公司工作。今年看来受访者代表的行业范围更广。然而,我们也简化了行业列表,以减少潜在重叠类别造成的困惑(例如,2018 年的“软件”和“互联网/网络服务”分开的类别在 2019 年合并为“技术”)。因此,这并非严格意义上的直接比较。例如,简化类别列表的一个影响可能是减少了将“软件”类别用作未明确列出的行业中编写 Go 软件的受访者的通用类别的现象。
Go 是一个成功的开源项目,但这并不意味着使用 Go 的开发者也在编写免费或开源软件。与往年一样,我们发现大多数受访者并非 Go 开源项目的频繁贡献者,75% 的人表示他们“不常”或“从不”贡献。随着 Go 社区的扩展,我们看到从未贡献过 Go 开源项目的受访者比例正在缓慢上升。
开发者工具
与往年一样,绝大多数调查受访者表示他们在 Linux 和 macOS 系统上使用 Go。这是我们的受访者与 StackOverflow 2019 年结果之间一个显著差异的领域:在我们的调查中,只有 20% 的受访者将 Windows 作为主要开发平台,而在 StackOverflow 中,这一比例为 45%。66% 的人使用 Linux,53% 的人使用 macOS——这两个比例都远高于 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 年以来一直保持稳定。
结果标准化改变了往年大多数这些数字。例如,同意“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”开头的四个选项中有三个下降,而其他所有选项都保持稳定或增加。因此,最好将此图表解释为 2019 年更准确的基线,以及 2016-2018 年的趋势。例如,我们认为自 2016 年以来构建返回 HTML 的 Web 服务的受访者比例一直在下降,但可能被低估了,因为这个回复总是位于长列表的底部。我们还按组织规模和行业进行了细分,但没有发现显著差异:受访者使用 Go 的方式似乎大致相似,无论他们是在小型科技初创公司还是大型零售企业工作。
一个相关问题询问了受访者使用 Go 的更广泛领域。迄今为止最常见的领域是 Web 开发(66%),但其他常见领域包括数据库(45%)、网络编程(42%)、系统编程(38%)和 DevOps 任务(37%)。
除了受访者正在构建的内容之外,我们还询问了他们使用的一些开发技术。绝大多数受访者表示他们依赖文本日志进行调试(88%),他们的自由文本回复表明这是因为替代工具难以有效使用。然而,本地逐步调试(例如使用 Delve)、性能分析以及使用竞态检测器进行测试并非不常见,大约 50% 的受访者至少依赖其中一种技术。
关于包管理,我们发现绝大多数受访者已经采用了 Go Modules(89%)。这对于开发者来说是一个巨大的转变,并且几乎整个社区似乎都在同时经历这一过程。
我们还发现 75% 的受访者评估当前 Go 版本用于生产环境,另有 12% 的人等待一个发布周期。这表明绝大多数 Go 开发者正在使用(或至少尝试使用)当前或前一个稳定版本,突显了平台即服务提供商快速支持 Go 新稳定版本的重要性。
云中的 Go
Go 在设计时就考虑到了现代分布式计算,我们希望继续改进使用 Go 构建云服务的开发者体验。今年我们扩展了关于云开发的问题,以更好地了解受访者如何与云提供商合作,他们对当前的开发者体验满意之处,以及可以改进的地方。如前所述,2018 年的一些结果似乎是异常值,例如自有服务器的意外低结果,以及 GCP 部署的意外高结果。
我们看到了两个明显的趋势
- 全球三大云提供商(亚马逊云服务 Amazon Web Services、谷歌云平台 Google Cloud Platform 和微软 Azure Microsoft Azure)在调查受访者中的使用量似乎都在呈上升趋势,而大多数其他提供商每年被较小比例的受访者使用。
- 部署到自有或公司服务器的本地部署持续减少,现在在统计上与 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 的受访者子集,而不是全部调查受访者。
那些认为 Go“不适合”他们工作的受访者给出了各种各样的原因和用例。最常见的原因是他们从事某种形式的前端开发(22%),例如 Web、桌面或移动应用的 GUI。另一个常见回复是受访者表示他们在某个领域工作,该领域已经有占主导地位的语言(9%),这使得使用 Go 成为挑战。一些受访者还告诉了我们他们指的是哪个领域(或只是提及了某个领域而没有提及另一种语言更常见),我们在下方通过“我从事 [领域]”行展示。受访者提到的另一个主要原因是对更高性能的需求(9%),特别是对于实时计算。
受访者报告的最大挑战与去年基本一致。Go 缺乏泛型和模块/包管理仍然位居榜首(分别占回复的 15% 和 12%),并且突出工具问题的受访者比例有所增加。这些数字与上面的图表不同,因为这个问题是针对所有受访者提出的,无论他们认为自己最大的 Go 采用障碍是什么。这三个问题都是 Go 团队今年的重点关注领域,我们希望在未来几个月内大幅改善开发者体验,特别是在模块、工具以及入门体验方面。
在任何语言中诊断故障和性能问题都可能具有挑战性。受访者告诉我们,他们在这两个方面的最大挑战并非 Go 的实现或工具特有的问题,而是一个更基础的问题:自我报告的知识、经验或最佳实践的不足。我们希望在今年晚些时候通过文档和其他教育材料来帮助弥补这些知识差距。其他主要问题确实涉及工具,特别是学习/使用 Go 调试和性能分析工具时感知到的不利成本/收益权衡,以及使工具在各种环境中工作(例如在容器中调试,或从生产系统获取性能分析文件)的挑战。
最后,当我们问什么会最能改善受访者编辑环境中的 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% 的人认同自己是女性。(这个问题本应使用“woman”而不是“female”。我们在 2020 年的调查草案中已经纠正了这个错误,并为此道歉。)我们强烈怀疑这 3% 低估了 Go 社区中的女性人数。例如,我们知道美国女性软件开发者回复 StackOverflow 开发者调查的比例 约为基于美国就业数据的预期比例的一半(11% 对 20%)。由于我们不知道美国受访者的比例,我们无法安全地从这些数字中推断,只能说实际比例可能高于 3%。此外,GDPR 要求我们改变询问敏感信息的方式,其中包括性别和传统上代表性不足的群体。不幸的是,这些变化导致我们无法将这些数据与往年进行有效比较。
认同代表性不足群体或选择不回答此问题的受访者,对“我在 Go 社区感到受欢迎”这一陈述表示不同意的比例高于那些不认同代表性不足群体的人(8% 对 4%),这突显了我们持续外展工作的重要性。
结论
我们希望您喜欢看到我们 2019 年开发者调查的结果。了解开发者的经验和挑战有助于我们规划和优先安排 2020 年的工作。再次对所有为本次调查做出贡献的人表示巨大的感谢——您的反馈正在帮助指引 Go 未来一年的方向。
下一篇文章:VS Code Go 扩展加入 Go 项目
上一篇文章:Go、Go 社区与疫情
博客索引