2020 年,我们的参与人数达到了 9,648 人,这个数据大约和2019 年时一样多。感谢您抽出宝贵的时间为社区提供了有关于您在使用 Go 时的一些见解!
您可能注意到一些问题的样本量 ("n=") 是比其他样本小的。这是因为某些问题是向所有人公开的,而另一些问题仅向随机的一部分受访者展示。
受访者统计问题可以帮助我们辨识出,哪些年度差异是由我们的调查受访者们的情绪或行为导致的。因为我们受访者特征和去年相似,所以我们可以有把握的相信受访者特征对年度差异变化的影响不大。
例如,从 2019 年到 2020 年,组织规模、开发者的经验和行业的分布大致相同。
几乎一半 (48%) 的受访者使用 Go 的时间不到两年。到 2020 年,我们已经很少能收到使用 Go 不到一年的人对调查的回应。
大多数人表示,他们会在工作 (76%) 和工作外 (62%) 时使用 Go。工作中使用 Go 的受访者比例逐年上升。
今年我们提出了有关主要工作职责的新问题。我们发现,有 70%的受访者的主要责任是开发软件和应用,但也有相当一部分受访者正在设计 IT 系统和体系结构。
与往年一样,我们发现大多数受访者并不是 Go 开源项目的频繁贡献者,有 75%的受访者表示他们 “很少” 或 “从不” 这么做。
与往年一样,绝大多数被调查者表示在 Linux(63%)和 macOS(55%)系统上使用 Go。随着时间的推移,主要在 Linux 上进行开发的受访者比例略有下降。
编辑器的偏好似乎第一次稳定了下来:VS Code 仍然是最受欢迎的编辑器(41%),其次是 Goland(35%)。这两类就占据了 76% 的比例,其他的编辑器喜好并没有像往年一样继续下降,
今年,我们要求受访者在假设他们拥有 100 个 “GopherCoins”(一种虚拟货币)的情况下,会花多少钱来优先改善他们的编辑器。代码自动补全功能获得的 GopherCions 的平均数量最高。 一半的受访者表示愿意花费 10 个或者更多的 GopherCoins 来改善这四个功能(代码补全、代码导航、编辑器性能和重构)。
大多数的受访者(63%)会花费他们 10-30% 的时间来重构,这表明重构是一项常见任务,并且我们希望研究一些方法来改善它。这也解释了为什么编辑器支持重构是获得投币数量最多的改进之一。
去年,我们询问了一些特定的开发技能,其中接近 90% 的受访者正在使用文本日志的方式进行调试,为了找出这个问题的原因,我们今年增加了一个后续的问题。结果表明,有 43% 的人是因为跨语言时可以使用相同的调试策略,还有 42% 的人更喜欢文本记录而不是其他的调试技术。但是,有 27% 的人是不知道如何开始使用 Go 的调试工具,还有 24% 的人从未尝试过使用 Go 的调试工具,因此就有机会在发现性、可用性和文档方面来改进调试工具。此外,由于四分之一的受访者从未尝试使用调试工具,因此该痛点可能被低估。
今年,我们是第一次询问人们对 Go 的整体满意度。92% 的受访者表示,在过去的一年里,他们在使用 Go 时感到非常满意。
这是我们第三年问” 你会推荐...“这样的净推荐值问题(NPS)。今年我们得到的 NPS 值为 61(“推荐者” 为 68%,“拒绝者” 为 6%),结果与 2019 年和 2018 年相比没有变化。
与前几年相似,有 91%的受访者表示他们更愿意将 Go 用于其下一个新项目。89%的人说 Go 在他们的团队表现很好。今年,我们看到认同 Go 对公司成功至关重要的受访者从 2019 年的 59%增加到 2020 年的 66%。在拥有 5,000 名或更多员工的组织中工作的受访者不太可能认同(63%),而那些在较小的组织中的受访者,更可能会认同(73%)。
与去年一样,我们要求受访者根据满意度和重要性对 Go 开发的特定领域进行评分。云服务,调试和模块(去年的改进重点)的满意度有所增加,而大多数重要性分数却保持不变。我们还引入了两个新主题:API 和 Web 框架。我们看到 Web 框架的满意度低于其他领域(64%)。对于大多数当前用户而言,它并不是那么重要(只有 28%的受访者表示它非常重要),但是对于潜在的 Go 开发人员来说,它可能是缺失的关键特性。
81%的受访者表示,使用 Go 时会感到非常高效。大型组织的受访者比小型组织的受访者更能感受到这一点。
我们听到,使用 Go 可以轻松快速地实现生产。我们询问了那些感受到 Go 的高效的受访者,他们花费多长的时间才能变得高效。93% 的人说用了不到一年的时间,大多数人在 3 个月内就感觉到了高效。
尽管与去年大致相同,但认同 “在 Go 社区中我感到受欢迎” 这一说法的受访者的百分比似乎随着时间的推移呈下降趋势,或者至少没有与其他领域保持相同的上升趋势。
我们还发现,认为 Go 的项目领导理解他们需求的受访者比例逐年显著上升(63%)。
所有这些结果表明,从大约两年开始,更多的认同与 Go 的体验提高相关。换句话说,受访者使用 Go 的时间越长,他们越可能同意这些陈述。
我们询问了一个关于如何使 Go 社区更受欢迎的开放问题。最普遍的建议(21%)是与学习资源和文档不同形式的改进/增加相关的。
构建 API/RPC 服务(74%)和 CLI(65%)仍然是 Go 的最常见用途。与去年相比,我们在选项的排序中引入了随机化之后,看不到任何重大变化。(在 2019 年之前,选择列表开头的选项不成比例。)我们还根据组织规模对此进行了细分,发现受访者在大型企业或小型组织中使用 Go 的方式相似,尽管大型组织使用 Go 来做返回 HTML 的 Web 服务的可能性更小。
今年,我们对被访者在家中还是在工作中用 Go 写哪种软件进行了更好的了解。尽管返回 HTML 的 Web 服务是最常见的第 4 个用例,但这是由于与工作无关的使用所致。与返回 HTML 的 Web 服务相比,更多的受访者将 Go 用于自动化/脚本,代理和守护程序以及用于工作的数据处理。大部分非常规用途(台式机/ GUI 应用程序,游戏和移动应用程序)是在工作以外编写的。
另一个新问题是,对于每个用例,受访者的满意度如何。CLI 的满意度最高,有 85%的受访者表示对 Go for CLI 的使用感到非常,中等或略微满意。Go 的常用用法往往具有较高的满意度得分,但满意度和受欢迎程度并不完全对应。例如,代理和守护程序的满意度比例第二高,但使用率排名第六。
其他后续问题探讨了不同的用例,例如,受访者使用其 CLI 的平台。Linux(93%)和 macOS(59%)的高占有率并不奇怪,因为开发人员对 Linux、macOS 和 Linux 云的使用率很高。但是,Windows 也成为了将近三分之一的 CLI 开发人员的目标。
仔细研究 Go 的数据处理可以发现,Kafka 是唯一被广泛采用的引擎,但是大多数受访者表示,他们将 Go 与自定义的数据处理引擎一起使用。
我们还询问了受访者使用 Go 的更大领域。到目前为止,最常见的领域是 Web 开发(68%),但其他常见的领域包括数据库(46%),DevOps(42%)网络编程(41%)和系统编程(40%)。
与去年相似,我们发现 76%的受访者会评估当前的 Go 版本以供生产使用,但是今年我们调整了时间范围,并且发现 60%的受访者在发布前或发布后 2 个月内开始评估新版本。这对于平台即服务提供商快速支持 Go 的新稳定版本方面是非常重要的。
今年,我们发现 Go 模块几乎被普遍采用,并且仅使用模块来管理软件包的受访者比例显着增加。96%的受访者表示,他们正在使用模块进行软件包管理,而去年这一比例为 89%。87%的被调查者表示他们仅使用模块来包管理,而去年为 71%。同时,其他软件包管理工具的使用已经减少了。
受访者对模块的满意度相比去年也有所提高。其中 77%的受访者表示,他们对模块感到非常,中度或略微满意,而这一比例在 2019 年为 68%。
大多数受访者表示,他们在使用官方文档时遇到困难。62%的受访者难以找到足够的信息来完全实现其应用程序的功能,并且三分之一以上的受访者则难以开始他们以前从未做过的事情。
官方文档中最有问题的领域是模块使用和 CLI 开发,有 20%的受访者认为模块文档稍微有用或根本没有帮助,而 16%的受访者面对关于 CLI 开发的文档也是这样认为的。
Go 在设计时就考虑了现代的分布式计算,我们希望继续改善开发人员使用 Go 构建云服务的体验。
部署在 AWS 和 Azure 的受访者见证了部署到托管 Kubernetes 平台的增长,现在分别为 40% 和 54%。Azure 看到将 Go 程序部署到 VM 的用户比例显著下降,容器使用率从 18%增长到 25%。同时,在 GCP(已经有很大比例的受访者报告了托管的 Kubernetes 使用情况)可以看到无服务器化的 Cloud Run 部署从 10%增长到 17%。
总体而言,大多数受访者对在三大主流云服务商提供的云上使用 Go 感到满意,并且统计数字与去年相比没有变化。受访者表示,对于 AWS(82%的满意)和 GCP(80%)上的 Go 开发,其满意程度相似。而 Azure 的满意度较低(满意度为 58%),自由回复中经常提到需要改进 Azure 的 Go SDK 和对 Azure 功能的 Go 版支持。
受访者不能继续使用 Go 的前几个主要原因是项目使用另一种语言进行开发(54%),工作团队更喜欢使用另一种语言(34%)以及 Go 本身缺乏一些关键特性(26%)。
今年,我们引入了一个新选项,“我已经在想用的任何地方都使用了 Go”,以便受访者可以选择不妨碍他们使用 Go 的选项。这大大降低了所有其他选项的选择率,但没有改变它们的相对顺序。我们还引入了一个 “缺乏关键框架” 选项。
如果我们仅看受访者不使用 Go 的原因,则可以更好地了解逐年趋势。使用另一种语言来处理现有项目和项目/团队/负责人对另一种语言的偏好正在减少。
在说 Go 缺乏他们所需语言特性的 26% 的受访者中,88% 的人认为泛型是 Go 缺乏的关键特性。其他重要缺失的特性是需要更好地错误处理(58%),空安全(44%),函数编程(42%)以及更强大/可扩展的类型系统(41%)。
需要明确的是,这些数字来自那些认为如果 Go 不缺失一个或多个关键特性,会更多地使用 Go 的受访者子集,而不是整个受访者群体。换个角度看,由于缺乏泛型,有 18%的受访者无法使用 Go。
受访者报告说,使用 Go 时遇到的最大挑战是 Go 缺乏泛型(18%),而模块/软件包管理以及学习曲线/最佳实践/文档的问题均占 13%。
今年,我们向受访者询问了他们用于回答与 Go 相关问题的前 5 个资源。去年,我们只要求前三个,因此结果不能直接比较,但是,StackOverflow 仍然是最受欢迎的资源,占 65%。阅读源代码(57%)仍然是另一种流行的资源,而对 godoc.org 的依赖(39%)大大减少了。软件包发现站点 pkg.go.dev 是今年第一次出现在列表,是 32%受访者的首选资源。使用 pkg.go.dev 的受访者更加认同在此能够快速找到所需的 Go 软件包/库:pkg.go.dev 用户为 91%,其他人为 82%。
多年来,未参加任何与 Go 相关活动的受访者的比例一直在上升。由于 Covid-19,今年我们修改了有关 Go 活动的问题,并发现超过四分之一的受访者在线上 Go 频道上花费的时间比往年多,有 14%的人参加了 Go 的虚拟会议,是去年的两倍。参加虚拟活动的人中有 64%表示这是他们的第一次虚拟活动。
我们发现 12%的受访者认为自己属于传统上代表性不足的群体(例如,种族,性别认同等),这个结果与 2019 年相同,而对此认同的 2%为女性,少于 2019 年(3%)。认同此想法的受访者与不认同的相比,对 “我在 Go 社区表示欢迎” 这一说法的异议率更高(10%vs. 4%)。这些问题使我们能够衡量社区中的多样性,并重视拓展和增长的机会。
我们今年在辅助技术的使用上又增加了一个问题,发现 8%的受访者正在使用某种形式的辅助技术。最常用的辅助技术是对比度或颜色设置(2%)。这大大提醒我们,我们的用户具有访问性需求,这也有助于在 Go 团队管理的网站上推动我们的某些设计决策。
Go 团队重视多样性和包容性,这不仅是做对的事情,还因为多样化的声音可以照亮我们的盲点,并最终使所有用户受益。根据数据隐私法规,我们询问敏感信息(包括性别和传统上代表性不足的群体)的方式已经改变,并且我们希望在未来使这些问题(尤其是有关性别多样性的问题)更具包容性。
感谢您与我们一起审查 2020 年开发者调查结果!了解开发人员的经验和挑战可帮助我们衡量进展并指导 Go 的未来。再次感谢为这项调查做出贡献的每个人 - 没有您,我们不可能做到。希望明年见!