Go 2019 开发者调查结果

本文为官方 Go Blog 的中文翻译，详见 翻译说明

Todd Kulesza
2020 年 4 月 20 日

回复情况!

首先, 我要向参与今年调查的数千名 Go 开发人员表示极大的感谢. 对于 2019 年, 我们收到了10,975 份回复, 几乎是去年的两倍 (《Go Blog 中文翻译》)! 我要代表团队的其他成员, 充分强调您花时间和精力向我们介绍您在 Go 方面的经验, 我们对此深表感谢. 谢谢!

关于往年的注意事项

敏锐的读者可能会注意到, 我们的年度比较与我们过去分享的数字并不完全一致. 原因是从 2016 年至 2018 年, 我们以开始调查的总人数作为分母, 计算了每个问题的百分比. 尽管这很不错而且很一致, 但它忽略了并非每个人都完成调查的事实 - 多达 40％ 的参与者在到达最后一页之前就停止了调查, 这意味着在调查的后面出现的问题似乎表现得更糟, 完全是因为他们后来才完成. 因此, 今年, 我们重新计算了所有结果 (包括本文中显示的 2016-2018 年答复), 以使用回答给定问题的人数作为该问题的分母. 我们在 x 轴上或图表图例中以 "n = [受访者人数]" 的形式包括了每个图表的 2019 年答复数量, 以使读者更好地理解每个图表背后的证据权重发现.

同样, 我们了解到, 在先前的调查中, 在回复列表中较早出现的选项的回复率不成比例. 为了解决这个问题, 我们在调查中添加了随机元素. 我们的一些多项选择题都包含没有逻辑顺序的选择列表, 例如 "我在 Go 中编写了以下内容: [应用程序类型列表]". 以前这些选择是按字母顺序排列的, 但在 2019 年, 它们以随机顺序呈现给每个参与者. 这意味着某些问题的按年比较在 2018 → 2019 期间无效, 但 2016-2018 年的趋势并未无效. 您可以认为这为 2019 年设定了更准确的基准. 在受访者可能会扫描特定名称 (例如其首选编辑器) 的情况下, 我们保留了字母顺序. 我们在下面明确指出适用于哪些问题.

第三个主要变化是使用开放式, 自由文本答复来改进我们对问题的分析. 去年, 我们使用机器学习对这些响应进行了大致 (但很快) 的分类. 今年, 两名研究人员对这些响应进行了手动分析和分类, 从而可以进行更精细的分析, 但无法与去年的数字进行有效比较. 像上面讨论的随机化一样, 此更改的目的是为我们提供 2019 年以后的可靠基准.

无需再费周折

这是一个很长的帖子. 我们选取了主要的部分:

• 我们受访者的人口统计数据与 Stack Overflow 的调查受访者相似, 这增加了我们对这些结果代表更多 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 老兵更有可能声称拥有 C/C++ 的专业知识, 而不太可能声称具有 JavaScript, TypeScript 和 PHP 的专业知识. 一个警告是, 这是自我报告的 "专业知识". 将其视为 "熟悉" 可能会更有用. 不管他们使用 Go 已有多长时间, 相比 Go 而言 Python 似乎都是大多数受访者更熟悉的语言.

去年, 我们询问了受访者从事的行业, 发现大多数人报告曾在软件, 互联网或网络服务公司工作. 今年看来, 受访者代表了更广泛的行业. 但是, 我们还简化了行业清单, 以减少潜在重叠类别的混淆 (例如, 2018 年将 "软件" 和 "互联网/网络服务" 的单独类别合并为 2019 年的 "技术"). 因此, 这并不是严格意义上的同类别比较. 例如, 简化类别列表的一种效果可能是减少 "软件" 类别的使用, 以防止针对未明确列出的行业编写 Go 软件的被调查者使用.

Go 是一个成功的开源项目, 但这并不意味着开发者和前几年一样, 我们发现大多数受访者并不是开源项目的频繁贡献者, 75% 的受访者表示他们 "很少" 或 "从不" 这样做. 随着 Go 社区的扩大, 我们看到从未参与过开源项目的受访者比例正在缓慢上升.

开发者工具

与往年一样, 绝大多数被调查者表示在 Linux 和 macOS 系统上使用 Go. 这是我们的受访者与 StackOverflow 的 2019 年结果之间存在很大差异的一个地方: 在我们的调查中, 只有 20％ 的受访者使用 Windows 作为主要开发平台, 而对于 StackOverflow 而言, 这一比例为 45％. Linux 的使用率为 66％, macOS 的使用率为 53％, 这两者都远远高于 StackOverflow 的受众, 后者分别报告了 25％ 和 30％.

今年, 编辑器整合的趋势仍在继续. GoLand 的使用量今年增长最快, 从 24％→34％ 上升. VS Code 的增长速度有所放缓, 但仍然是受访者中最受欢迎的编辑, 占41％. 结合起来, 这两个编辑器现在被 3/4 的受访者中的首选.

其他所有编辑人员的数量都有所减少. 这并不意味着根本就没有使用那些编辑器, 但是它们并不是受访者所说的 更好 用来编写 Go 代码的工具.

今年, 我们增加了一个有关内部 Go 文档工具的问题, 例如 gddo. 少数受访者 (6％) 表示他们的组织运行自己的 Go 文档服务器, 尽管当我们查看大型组织的受访者 (拥有至少 5,000名 员工) 时, 这一比例几乎翻了一番 (达到11％). 对受访者的后续询问表示他们的组织已停止运行其自己的文档服务器, 这表明退休该服务器的首要原因是人们认为收益较低 (23％) 与最初设置该服务器所需的工作量以及保持它 (38％).

对 Go 的感情

大多数受访者都认为 Go 在他们的团队中表现良好 (86％), 并且他们希望将其用于下一个项目(89％). 我们还发现, 超过一半的受访者 (59％) 认为 Go 对他们公司的成功至关重要. 自 2016 年以来, 所有这些指标一直保持稳定.

对结果进行归一化改变了以前年份的大多数数字. 例如, 由于参与者的离职, 同意 "Go 对我的团队来说很好" 这一说法的受访者比例以前在 50 年代和 6 0年代. 当我们删除从未见过该问题的参与者时, 我们发现自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 个减少了, 而其他所有条件保持稳定或增加. 因此, 最好将此图表解释为具有 2016-2018 年趋势的 2019 年更准确的基线. 例如, 我们认为自 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％ 和 42％)。

通过查看受访者使用的云平台类型，我们可以看到主要提供商之间的差异。部署到 AWS 和 Azure 的受访者最有可能直接使用 VM（分别为 65％ 和 51％），而部署到 GCP 的受访者使用托管 Kubernetes 平台（GKE，64％）的可能性几乎是 VM 的两倍（ 35％）。我们还发现，部署到 AWS 的受访者使用托管 Kubernetes 平台的可能性相同（32％），而使用无服务器托管平台（AWS Lambda，33％）的可能性相同。 GCP（17％）和 Azure（7％）的受访者使用无服务器平台的比例均较低，而自由文本响应表明，主要原因是这些平台上对最新 Go 运行时的支持延迟。

总体而言，大多数受访者对在所有三大主要云提供商上使用 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 语言不是 "合适的语言" 的受访者有多种原因和用例. 最常见的是他们从事某种形式的前端开发 (22％), 例如用于 Web, 桌面或移动的 GUI. 另一个普遍的回答是, 受访者说他们在一个已经占主导地位的语言 (9％) 的领域中工作, 这使得使用其他语言成为一个挑战. 一些受访者还告诉我们他们所指的是哪个地区 (或简单地提到一个地区而不提及另一种更常见的语言), 我们通过下面的 "我在[哪里]工作" 行来显示. 受访者提到的另一个首要原因是需要更好的性能 (9％), 特别是对于实时计算.

受访者回复的最大挑战与去年基本保持一致. Go 缺乏通用性和模块/软件包管理仍然是最主要的问题 (分别占回复的 15％ 和 12％), 并且强调工具问题的受访者比例有所增加. 这些数字与上面的图表不同, 因为这个问题是针对所有受访者而提出的, 无论他们说最大的 Go 采用阻止者是什么. 所有这三个都是今年 Go 团队关注的领域, 我们希望在未来几个月中极大地改善开发人员的体验, 尤其是在模块, 工具和入门经验方面.

用任何一种语言来诊断故障和性能问题都可能具有挑战性. 受访者告诉我们, 这两个方面的最大挑战不是 Go 的实施或工具所特有的, 而是一个更根本的问题: 自我报告的缺乏知识, 经验或最佳实践. 我们希望在今年晚些时候通过文档和其他教育材料来帮助解决这些知识差距. 其他主要问题的确涉及工具, 尤其是在学习/使用 Go 的调试和概要分析工具时, 在成本/收益方面存在不利的取舍, 以及使工具在各种环境下工作的挑战. (例如, 在容器中调试, 或从生产系统中获取性能概况.

最后，当我们问到在受访者的编辑环境中最能改善 Go 支持的内容时，最常见的回答是对语言服务器的总体改进或更好的支持（gopls，19％）。这是预料之中的，因为 gopls 替代了大约 80 种现存的工具，并且仍处于测试阶段。当受访者更具体地说明他们希望获得的改进时，他们最有可能报告调试经验（14％）和更快或更可靠的代码完成（13％）。许多参与者还明确提到使用 gopls（8％）时需要频繁重新启动 VS Code 的需求；自从本次调查在现场进行以来（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％ vs 20％）。由于我们不知道美国的回应比例，因此无法安全地从这些数字中推断出实际比例可能会高于 3％。此外，GDPR 要求我们改变对敏感信息的询问方式，其中包括性别和传统上代表性不足的群体。不幸的是，这些变化使我们无法将这些数字与以前的年份进行有效比较。

识别出代表性不足的群体或宁愿不回答该问题的受访者，与不认同代表性不足的群体的受访者相比，对「我在 Go 社区中表示欢迎」这一陈述的异议率更高（8％ 对 4％）。我们持续开展宣传工作的重要性。

总结

我们希望您喜欢我们的 2019 年开发人员调查结果. 了解开发人员的经验和挑战有助于我们计划和确定 2020 年的工作重点. 再次感谢对本次调查做出贡献的每个人 - 您的反馈意见将帮助 Go 来年及以后的发展方向.

本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://learnku.com/docs/go-blog/survey2...

译文地址：https://learnku.com/docs/go-blog/survey2...