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 的未来。再次感谢为这项调查做出贡献的每个人 - 没有您，我们不可能做到。希望明年见！
