受访者正在使用 Go 来解决类似的问题，特别是构建 API/RPC 服务和 CLI，和他们工作的组织规模大小关系不大；
大多数团队试图快速更新到最新的 Go 版本；当第三方供应商迟迟不支持当前的 Go 版本时，就会给开发者造成采用障碍；
现在 Go 生态系统中几乎所有人都在使用go module，但围绕包管理的一些混乱仍然存在；
需要改进的高优先级领域包括调试、go module 使用以及与云服务交互的体验改善；
VS Code 和 GoLand 的使用量持续增加；现在每 4 个受访者中就有 3 个首选它们。
2020 年 6 月，vscode-go 扩展(vscode 上的 go 标准插件)将主代码库从 github.com/microsoft/vscode-go 迁移到 github.com/golang/vscode-go，成为 Go 官方项目的一部分。
同在 2020 年 6 月，pkg.go.dev 网站开源！该网站是 Go 团队在 Go 社区建设方面做出的主要工作，开源后的 pkg.go.dev 将接收更多来自社区的想法和改进意见，比如：11 月，pkg.go.dev 就发布了新版页面设计；原 godoc.org 的请求也被重定向到 pkg.go.dev(广大 gopher 可能需要一段时间来适应这种改变)。
2020 年 8 月，Go 1.15 版本发布，其主要的变动点包括：
GOPROXY 新增以管道符为分隔符的代理列表值；
module cache 的存储路径可设置;
改善派生自原生类型的自定义类型变量在 panic 时的输出形式；
将小整数([0,255])转换为 interface 类型值时将不会额外分配内存；
加入更现代化的链接器(linker)，新链接器的性能要提高 20%，内存占用减少 30%；
增加 tzdata 包。
2020 年 11 月初，全球最具影响力的 Go 语言技术大会GopherCon 2020[8]在线上举行！Austin Clements 详细讲解了 Go 1.14 加入的基于系统信号的抢占式调度器；Go 语言之父之一的 Robert Griesemer 讲解了Go 泛型当前的状态以及未来的计划。会后 Russ Cox 确认了 Go 团队将在 Go 1.18 版本中加入 Go 泛型(类型参数)作为试验特性；
2020 年 11 月 10 日，Russ Cox 代表 Go 核心开发团队发文庆祝Go 语言发布 11 周年，在文中他回顾了 Go 这一年来的收获以及对 2021 年Go 1.16和 Go 1.17 的展望。文中他还提到了 GOPATH 的历史使命即将结束，Go 将开启全面 module-aware 模式的 Go 工具链时代！
2020 年 12 月中旬，Go 1.16beta1 发布。在 Go 1.16 中，Go 将原生提供对 Apple M1 芯片(darwin/arm64)的支持；同时，在 Go 1.16 中 go module 将成为默认包依赖管理机制；Go 1.16 还提供了支持在 Go 二进制文件中嵌入静态文件的官方原生方案，支持对 init 函数的执行时间和内存消耗的跟踪，链接器性能得到进一步优化等。
今年笔者在知乎上滞留的时间比往年要长一些，看到很多人问与 Go 相关的一些问题，大致都是询问有关 Go 语言前景的，比如：
2020 年以后是 Go 语言的天下吗？
2020 年各个大厂内部 Go 语言开发环境是怎样的呢？有什么可以分享的经验吗？
Go 语言前景如何？
2021 年后哪个后端编程语言会越来越流行？
无论上述问题的题目有何不同，其本质的疑问都是“Go 语言前景/钱景如何，值不值得投入去学习?”。那么是否存在一种成熟的方法能相对客观地描会出 Go 语言的发展态势并能对未来 Go 的走势做出指导呢？我想 Gartner 的技术成熟度曲线（The Hype Cycle）或许可以一试。我们知道 Gartner 的技术成熟度曲线又叫技术循环曲线，是企业用来评估新科技是否要采用或采用时机的一种可视化方法，它利用时间轴与该技术在市面上的可见度(媒体曝光度)决定要不要采用以及何时该种新科技，下面就是一条典型的技术成熟度曲线的形状：同理，将该技术成熟度曲线应用于某种编程语言，比如 Go，我们就可以用它来判断该编程语言所处的成熟阶段以辅助决定要不要采用以及何时采用该门语言。我们从知名的 TIOBE 编程语言指数排行榜获取 Go 从 2009 年开源以来至今的指数曲线图，并且根据Go 版本发布史在图中标记出了各个时段的 Go 发布版本：对比上面的 Gartner 成熟度曲线，相信你肯定有所发现。我们共同来解释一下：
Go 语言从 2009 年宣布开源以来，经历了两次“高峰”：一次是 2009 年刚刚宣布开源后，一次是在 Go1.7~Go 1.9 期间。显然，第一次的高峰实际上是一个“假高峰”，那时的 Go 连 1.0 版本都尚未发布，我们完全可以将其“剔除”掉。
从图中来看，Go 语言的技术萌芽期是比较长的，从 2012 年的 Go 1.0 一直持续到 2015 年的Go 1.5；
Go 1.5 版本的自举以及 Go 垃圾回收延迟的大幅下降“引爆”了 Go 的“媒体曝光度”，Go 技术的“期望膨胀期”开始，经历从Go 1.6 到Go 1.9 版本的发布后，业界对 Go 的期望达到了峰值；
从 Go 1.10 开始，Go 似乎变得“仿徨”起来，原本期望 Go“一统天下”的愿望没能实现，全面出击失败后，期望的落空导致了人们对Go 产生了“功能孱弱劣势”的印象，于是 Go 在 Go 1.11 发布前跌到了“泡沫破裂”的谷底；
Go 1.11 引入了Go module，给社区解决Go 包依赖问题打了一剂强心剂，于是 Go 又开始了缓慢的爬升；
从 TIOBE 提供的曲线来看，Go 1.12到Go 1.15 版本的发布让我们有信心认为 Go 已经进入了“稳步爬升的光明期”。
到此，我相信知乎上的很多问题都应该迎刃而解了，剩下的只是如何学习 Go 的细节和如何 Go 进阶了。不过可能还有很多朋友会问，Go 何时能达到实质生产高峰期呢？这个问题真不好回答。但进入了“稳步爬升的光明期”后的 Go 到达实质生产高峰期只是一个时间问题了，也许 2022 年初发布的支持 Go 泛型特性的 Go 1.18 版本会快速推动 Go 向更高阶段进发！
展望 Go 的 2021：继续蓄力，迎接下一个“引爆点”
促使 Go 回到“稳步爬升光明期”的 go module 机制将在 2021 年年初正式发布的 Go 1.16 中成为默认包依赖管理机制。而Go 1.16 版本也已经处于特性冻结并发布了 beta1 版本的阶段，其更多特性可以参考我的“Go 1.16 新功能特性不完全前瞻”一文。将于 2021 年八月发布的Go 1.17 的里程碑已经建立, 从里程碑的内容来看，已基本确定加入的功能特性和改进包括：
针对 x86-64 的新的基于寄存器的调用约定（不破坏现有程序集！），这将使程序与主流语言的 ABI 模型保持一致，并且整体更快；
加入 build 指示器新语法：//go:build；
一个十多年前的 issue被 Go 团队 accept：使用(*[4]int)(x)语法将切片 x 转型为一个数组类型指针(*[4]int)。
当然 Go 1.17 还会持续优化链接器，更多功能特性和改进还待 Go 团队策划补充。而万众期待的 Go 泛型依然会继续打磨，从 2016 年 Ian Lance Taylor 提出“Go should have generics”的设计草案以来，Go 泛型草案至今已经讨论了 4 年多了，这再次证明了 Go 团队对于这类会显著增加 Go 复杂性的特性是多么地“慎之又慎”。虽然 Go 团队初步确定了在 Go 1.18 版本中将 Go 泛型（类型参数）落地，但近期 Go 项目中关于 Go 泛型的主 issue：proposal: spec: generic programming facilities 中仍然有不少反对的声音。Go 团队在“继续保持 Go 简单”的道路上真是任重道远啊！总之，2021 年，Go 将继续稳步爬升，也许爬的并没有那么快，但在我看来，这是在积蓄力量，等待着下一个引爆点。
小结
Go 在新冠疫情大流行的历史时期依旧步行稳健，为下一个“引爆点”积极蓄力。Go 在自己传统领域依旧存在明显优势，比如：企业级应用、基础设施、中间件、微服务 API、命令行应用等，并且在这些领域取得了越来越多开发者的青睐。Go 在其他领域也有“意外收获”，比如：在黑客工具领域，Go 已经逐渐威胁着 Python 的龙头地位了，显然语法简单、原生并发、自带“电池”、轻松跨平台的编译以及编译为独立二进制文件的 Go 与黑客的需求十分契合。不过，在安全领域成为了进攻“武器”，这想必是 Go 设计者们所意料不到的。
文章评论