Go Developer Survey 2023 Q1 Results 已经出炉!
以下为译文:
原文地址:https://go.dev/blog/survey2023-q1-results
我们很高兴与您分享2023年1月版Go开发者调查结果。感谢 5,844 位调研者与我们分享了他们如何使用 Go,他们在使用 Go 过程中遇到最大的挑战以及他们未来需要改进的首页任务。这些结果有助于 Go 团队聚集于对社区最重要的领域,我们希望这些见解也有助于为其他为 Go 生态系统作出贡献和支持的人提供信息。
在整篇文章中,我们使用调查回复图表为我们的结论提供证据支撑。所有这些图表都采用了类似的格式。标题是调研者看到的确切问题。除非另有说明,否则问题均有多个选项,并且参与者只能选择一个答案选项。每个图表的副标题都会告诉您是否允许多项选择,或者是一个开放式文本框而不是多项选择题。对于开放式文本回复的图表,Go 团队成员进行了阅读并手动分类了所有回复。许多开放式问题引起了五花八门的回复;为了保持图表尺寸合理,我们将它们精简为前10 ~ 15 个主题,剩下的主题归类到“其他”下面。在合适的情况下,我们还包括了一个“无”类别。
为了帮助每个读者了解每个结论背后的证据权重,我们包括了误差线,显示 95% 的响应置信区间;较窄的误差条表示置信度增加。有时两个或多个响应有重叠的误差条,这意味着这些响应的相对顺序在统计上没有意义(即响应有效地联系在一起)。每个图表的右下角显示图表中包含其回答的人数,形式为“n=[调研者人数]”。
大多数调研受访者“自行选择”通过 Go blog上的链接,Twitter 上的 @golang 频道或者其他 Go 社交渠道访问调查来参与的。不关注这些渠道的人可能会与密切关注这些渠道的人做出不同的响应。大约四分之一的受访者是随机抽取的,这意味着他们在看到 VS Code 中的提示后对调查做出了回应(2023 年 1 月 18 日至 2 月 8 日期间使用 VS Code Go 插件的每个人都有 10% 的机会收到此随机提示 )。这个随机抽样的小组帮助我们将这些发现推广到更大的 Go 开发者社区。 大多数调查问题显示这些组之间没有有意义的差异,但在少数具有重要差异的情况下,读者会看到将响应分解为“随机样本”和“自选”组的图表。
我们的受访者统计数据与我们上次调查相比没有显着变化。 与之前的周期一致,Go 主要用于科技行业,约 80% 的受访者表示他们在工作中使用 Go 编程。 总体而言,调查受访者在过去一年中对 Go 趋于满意,92% 的人表示他们比较满意或非常满意。 与其他语言相比,我们的受访者花费了大量的时间在Go上编程。大约三分之一的受访者甚至维护着一个开源的Go模块。我们认识到,我们的调查对象是由那些成功采用 Go、经常使用 Go 并且对使用 Go 感到满意的人组成的。为了确定在满足社区需求方面的潜在差距,我们研究了不同的受访者子组,以了解他们如何以不同的方式使用 Go 或有不同的优先级。例如,今年我们研究了不同样本来源(即 Go 博客或通过 VS 代码插件)、不同工作角色、组织规模和 Go 经验水平之间的反应有何不同。 最有趣的差异是经验水平之间的差异。
以往,我们使用受访者使用 Go 的时间(以月/年为单位)作为代表来深入了解不同经验水平的结果差异。今年我们尝试了一个新的细分问题,“你的 Go 经验水平如何?”,看看自我认同是否是比将不同的时间间隔放在一起更有用的检查 Go 经验的方法。由于像“新手”或“专家”这样的分类术语可能因人而异,我们提供了一个描述来帮助使这些桶更加客观。这些选项是:
我们发现受访者使用 Go 的时间长短与其自我认定的经验水平之间存在适度相关性 (⍴ = .66)。 这意味着经验水平量表虽然与时间量表相似,但可能会给我们一些新的见解,让我们了解受访者的经验有何不同。 例如,受访者花在用 Go 写作的时间与他们花在用其他语言写作的时间的比例与他们自我认同的经验水平的相关性比与他们使用 Go 的时间长短的相关性更强。
在我们使用这种细分的分析中,我们通常会排除“了解”类别,因为他们不会被认为具有回答问题所需的经验,并且只代表大约 1% 的受访者。
我们随机抽取的组中新手受访者的比例高于自选组,这表明那里有更多我们不经常听到的新 Gophers。由于他们是通过Go VS Code插件进行抽样调查的,我们可能期望这个群体比其他经验水平的人更可能喜欢使用VS Code或者更喜欢在Windows上开发。虽然这是事实,但无论他们是否通过VS Code插件进行回应,新手也比其他经验水平的人更有可能在Windows上开发。 可能有很多原因导致我们没有看到更高经验水平的Windows用户比例。例如,Windows用户可能更容易遇到困难并停止使用Go,或者可能存在与Go无关的更广泛的操作系统使用趋势。无论如何,我们应该在未来的研究中纳入更多的Windows用户,以确保我们提供一个包容性的入职体验。
根据受访者现在使用Go的情况,经验丰富的Gophers倾向于将Go用于更多类型的应用。例如,专家至少在四个领域使用 Go 开发,而普通新手仅在两个领域使用 Go 开发。这就是为什么在每个用例中,新手和专家使用Go的比例有很大差异。然而,前两种用途,即API/RPC服务和CLI,是所有经验水平的顶级用例。
我们在 GUI 和网站/Web 服务(返回 HTML)方面看到了更多有趣的趋势。 所有经验水平的人都以大致相同的比例使用 Go for Desktop / GUI 应用程序。 这给了我们证据,对 GUI 的渴望不仅仅来自寻找有趣的入门项目的新 Gophers,而是来自整个经验范围。
返回 HTML 的网站/服务显示出类似的趋势。一种解释可能是这是一些人 Go 之旅早期的常见用例(因为它是新手最常见的前 3 名),或者新手更有可能在返回 HTML 的网站或 Web 服务上工作。在调查的后期,我们询问了受访者,“您在哪个领域(如果有)没有使用 Go,但最想使用?” 尽管许多受访者 (29%) 表示他们已经在任何他们想去的地方使用 Go,但扩大使用量的前两个领域是 GUI / 桌面和 AI / ML 应用程序。这在不同组织规模和工作角色的群体中是一致的,但经验水平不同。 新手更愿意使用 Go 的第一个领域是返回 HTML 的网站/Web 服务。
在一个开放式文本问题中,29 名表示愿意将 Go 用于返回 HTML 的网站/Web 服务的受访者中有 12 名表示他们被阻止是因为其他语言具有更好地支持此用例的框架。当其他语言已经拥有满足这些需求的框架时,更有经验的 Go 开发人员可能不会尝试或期望将 Go 用于此用例。 就像其中一位受访者所说,“使用其他语言(如 PHP 或 Ruby)通常更容易实现这一点。 部分原因在于这些语言中存在的优秀框架。”
新手对 Web 开发感兴趣的另一个解释可能与他们对 JavaScript / TypeScript 的使用有关。与经验丰富的受访者相比,新手花在JavaScript/TypeScript编写上的时间更多。对网络的兴趣较高,可能与新手受访者目前用其他语言从事的工作有关,也可能表明他们对网络技术的普遍兴趣。在未来,我们希望能更多地了解这个用例,以及如何帮助新的Gophers在对他们最有用的领域开始使用Go。
在每个调查周期,我们都会询问受访者使用 Go 时最大的挑战是什么。从历史访问来看,泛型的缺乏是最常被提及的难题 —— 例如,这是2020年最常见的回答,约 18% 的受访者有提到过。自从引入泛型以来,错误处理 (12%) 和学习/最佳实践/文档 (11%) 出现在一长串问题的前面,而不是任何一个问题变得更加频繁。
关于错误处理的反馈往往将问题描述为冗长的处理。从表面上看,这可能反映出编写重复代码很无聊或烦人的。然而,错误处理不仅仅是编写模板的烦扰,还可能影响受访者的调试能力。 一位受访者简明扼要地说明了这个问题: “错误处理会造成混乱,如果处理不当(没有堆栈跟踪),很容易掩盖问题”
“Using Go effectively. Easy to learn, hard to master.” “有效地使用 Go。 易学难精。” 我们听说 Go 很容易学习,之前的一项调查显示,超过 70%[1] 的受访者在第一年内使用 Go 感觉很有效率,但学习 Go 最佳实践被认为是使用 Go 的最大挑战之一 。今年的受访者告诉我们,围绕代码结构的最佳实践以及推荐的工具和库没有很好的文档记录,这给初学者和团队保持代码一致性带来了挑战。学习编写地道的 Go 对于那些来自其他编程范式的人来说尤其具有挑战性。 对 Go 更有经验的受访者证明,当开发人员不遵循编写惯用 Go 的最佳实践时,它会损害共享项目的一致性和质量。
Go 模块维护者是 Go 社区的重要成员,帮助发展和维持我们包生态系统的健康。今年,我们计划与模块维护者进行研讨,以确定支持软件包生态系统稳定和增长的机会,并帮助在组织内提高 Go 的采用率。为了给这项研究提供信息,我们在调查中引入了一个问题,以了解开源维护者目前面临的最大难题。 维护人员面临的最大挑战是保持依赖关系最新和版本控制方面的困难,包括避免、识别或知道何时引入重大更改。 这些见解以及未来研究的结果将有助于制定策略,以支持维护者保持 Go 生态系统的稳定和安全。
今年我们询问了受访者在部署 Go 代码时面临的最大挑战是什么。 “易于部署”通常被认为是使用 Go 的原因,但在最近的一项研究中,我们收到了截然相反的一些反馈,这促使我们探索部署 Go 代码时的潜在问题。在我们的开放文本回复中,到目前为止,最常见的主题是难以与 cgo 交叉编译(16%),遥遥领先排在第二对 WebAssembly 或 WASI 的支持(7%)。
今年,我们使用了我们在之前的调查中使用的优先级问题,该问题基于购买功能的优先级排序方法。受访者获得了 10 个“gophercoins”,并被要求将它们分发到他们希望看到改进的区域。受访者被随机分配了三个可能的问题之一,每个问题包含七个与工具、安全性或编译器和运行时相关的项目。这种方法使我们能够询问与每个重点领域相关的项目,而不会用三组认知要求高的优先级排序问题让受访者负担过重。
在活动结束时,我们给了受访者一个开放的文本提示,告诉我们他们认为明年 Go 团队应该优先考虑的任何领域,无论他们把硬币花在了哪些项目上。例如,如果受访者看到了安全部分,但他们并不太关心安全性,他们仍然有机会在开放文本区域告诉我们。
我们选择这些项目来测试我们关于安全实践对社区的相对重要性的假设。 这些是向参与者描述的七个项目:
呼声最高安全特性是 Web 和 SQL 库在默认情况下是安全的,以避免在 Web 服务器代码中引入漏洞,但前四项特性都与避免引入漏洞有关。对安全默认设置的渴望与之前的安全研究一致,该研究表明开发人员希望在安全问题上“左移”:开发团队通常没有时间或资源来解决安全问题,因此重视那些首先减少引入安全问题的可能性的工具。第二个最常见的项目是安全最佳实践指南,向大多数受访者强调了最佳实践文档与新工具或功能相比的高价值。
我们在这个问题中包含的项目的灵感来自 VS Code 插件用户的反馈。 我们想知道哪些工具和 IDE 改进对可能使用其他 IDE 或编辑器的更广泛的受众最有帮助。
呼声最多的编辑器功能是支持查找实现接口的类型以及由类型和重构工具实现的接口。我们还看到了一个有趣的区别,即受访者如何根据首选编辑器的使用来花费他们的gophercoins。最值得注意的是,VS Code 用户在重构上花费的 gophercoins 比 GoLand 用户多,这表明目前 GoLand 比 VS Code 更好地支持自动代码转换。
我们这部分的关键问题是确定受访者是否希望默认情况下有更好的性能、更好的优化工具,或者只是更好地理解如何编写高性能的 Go 代码。
到目前为止,这份清单中呼声最高的项目是优化指南。这在组织规模、工作角色和经验水平上是一致的。我们又问了一个问题,即受访者是否有资源成本方面的担忧。大多数受访者(55%)说他们没有任何成本顾虑,但那些对资源成本有顾虑的人比那些没有顾虑的人在降低计算成本和内存成本上花费了更多的 gophercoins(平均2.0)。然而,即使是那些关心资源成本的人,在优化指南上的花费也差不多(平均 1.9 gophercoins)。这是一个强烈的信号,表明为 Go 开发人员提供理解和优化 Go 性能的指导目前比额外的编译器和运行时性能改进更有价值。
感谢您与我们一起回顾 2023 年首次开发者调查的结果! 了解开发人员的经验和难题有助于我们优先考虑如何最好地为 Go 社区服务。 我们发现了一些特别有用的要点:
再次感谢所有为本次调查做出回应和贡献的人——没有你们,我们不可能完成这项调查。 我们希望在今年晚些时候在下一次调查中见到您。
[1] https://go.dev/blog/survey2020-results#TOC_6.2
译文可能会有一些不准确或者错误,如有发现,欢迎指证。