本文是“2021 InfoQ 年度技术盘点与展望”系列文章之一，由 InfoQ 编辑部制作呈现，重点聚焦编程语言领域在 2021 年的重要进展、动态，希望能帮助你准确把握 2021 年编程语言领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。

“InfoQ 年度技术盘点与展望”是 InfoQ 全年最重要的内容选题之一，将涵盖架构、AI、大数据、大前端、云计算、数据库、中间件、操作系统、开源、编程语言十大领域，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。

特此感谢
· 阿里云程序语言与编译器团队负责人 李三红
· Go 语言编程专家 郝林
· Julia 社区核心成员 田俊、陈久宁
· 独立咨询顾问 /《Rust 编程之道》作者 张汉东
· JetBrains 技术专家 / 布道师 范圣佑
· 英特尔高级技术经理 王鑫

对本文的贡献。
他们都以直接或间接的形式，参与建设该篇文章，部分内容还以特别策划的形式独立成文，出现在盘点合集中。可以说，他们的真知灼见，是该盘点能与大家见面的关键。

需要声明的是，编程语言不能算作一个真正意义上的“技术领域”，因此它在本系列盘点中，显得尤为特殊。通常，当我们谈及一个独立的技术领域时，往往意味着该技术存在相对独立的商业价值、产业链、开发者群体。但编程语言只是个实现工具，同时又是整个 IT 世界的基础设施，这种矛盾让对编程语言的盘点显得有点沉闷，却又非常必要。在电影《天国王朝》里，主角贝里安问萨拉丁，耶路撒冷有什么意义？萨拉丁回答道：“Nothing”，随后又说道：“Everything”。同样的台词，套用在“编程语言”身上，或许刚好合适。

另外需要指出的是，IEEE 将编程语言以四个标签划分，分别是：用于开发网站和应用的语言（Web）、用于企业、桌面和科学应用的语言（Enterprise）、用于移动设备端的语言（Mobile）以及用于嵌入式环境的语言（Embedded）。

但在本文中，凡在超过 2-3 个标签领域都有广泛应用的编程语言，我们将其称之为“通用型语言”，以将 C/C 、Java 等语言和 JavaScript、R 等语言做好区分。我们将先对 2021 编程语言宏观层面的发展情况做个回顾，再对 Kotlin、Rust、Go、Julia、WebAssembly 五种较有代表性语言的具体发展作垂直解析。

2021 编程语言核心趋势

通用型语言：关注硬件性能及异构编程

近两年业界出现一种声音：摩尔定律已经失效了。这主要源于主流硬件厂商在 14nm 工艺上的长时间停滞，以及英伟达 CEO 黄仁勋在 2019 年 CES 展会上的发言：“摩尔定律过去是每 5 年增长 10 倍，每 10 年增长 100 倍。而如今，摩尔定律每年只能增长几个百分点，每 10 年可能只有 2 倍。因此，摩尔定律结束了。”

诚然，这个判断所引起的争议是非常大的，无论是苹果 M1 芯片，还是亚马逊云科技的 Graviton3 都在晶体管密度上延续了“摩尔定律”的判断。但在所有担忧背后，是 ioT 、AI，乃至元宇宙引发的越来越旺盛的算力需求与硬件工艺极限之间的矛盾。

放在今日，则深刻地影响了通用型编程语言的发展——从早期如何追求单核环境下的极致性能，到今日如何充分利用多核算力。

对协程的支持，就很好地反映了主流编程语言关注点的转移。2021 最重要的一个动态，当数 2021 年 11 月第三周，Java 即将支持虚拟线程（协程）的消息。消息来自 Oracle 提交的一份 JDK 增强建议（JEP）草案，草案要求将虚拟线程作为 Java 标准版的一部分进行预览。

草案中提到虚拟线程将补充 Java 的平台线程（代表操作系统线程），采用轻量级的用户模式线程实现，将更有效地利用可用的硬件，并大大降低成本。虚拟线程目的是更好地支持编写和维护高吞吐量并发应用程序。

这则消息，意味着最主流的编程语言已经全部支持或正在支持协程，包括 C 、Python、C#、Go（原生） 。这也代表着对硬件性能利用率的关注，已成为各家编程语言的大势所趋。Python 是其中尤为典型的例子，与 Google TPU 、TensorFlow 生态的高度契合，助其第五次问鼎 TIOBE 年度编程语言。

另外需要重点提及的，是异构编程。异构编程是对“编程语言 & 硬件性能”这个议题在宽度上的延展。2021 年，华为发布了北冥多样性计算融合架构，其中包含了毕晟 C 及其他组件，而这里的毕晟 C ，主要是服务于跨 CPU、GPU 算力编程的需求。这是国产基础软件，在编程语言层面向前迈进的一大步。

如果从这个时间点向前查找，我们会发现在 2020 年 10 月，英特尔发布了 oneAPI 1.0，目标在于简化跨不同计算体系结构的应用程序开发；2008 年，苹果带头创建了跨平台计算框架 OpenCL；而在更早的十余年前，英伟达就发布了 CUDA，用于支持 GPU 编程。

问题在于，异构编程，无论在语言还是框架层面，学习成本都非常的高。从本质上讲，异构编程要求开发者对硬件之间的差异性有深刻的洞察，并能结合硬件差异做异常精细的性能调优。这导致团队引入后，研发效率相对降低（学习成本、迁移成本）。所以常规的通用型语言，也会提供异构编程接口作为折中，比如 Java TornadoVM 就是用于支持异构硬件的特性。

况且，异构编程底层支持工具的推出和更新，重度依赖于自研硬件的各个厂商。但当今的硬件市场，不但没有收敛，反而有更加碎片化的趋势。各家的异构编程框架，往往只注重适配自己的体系，对其他的行业主流硬件既不愿过问，也没有足够的资源过问，这也为底层开发者的工作开展增加了难度。

放眼未来，开源，或许是打破现存问题的一种更好的组织模式。

我们既要性能也要安全，研发效能则需特别讨论

这随之引发了另一矛盾：性能和研发效率，通常是相悖的。在此前 InfoQ 对“Java 之父” James Gosling 的采访中，他用 Java 和 JavaScript 的区别来说明这个问题。至于内存安全，在相当漫长的时间里，在以 C/C 为底层技术栈的开发群体内，则通常不在考虑范围内。

Rust 在 2021 年的大火，为全行业提供了新的启发。在 InfoQ 2021 编程语言榜单 中，Rust 无论是关注度还是期望值，都紧随 Go 语言之后。若单论关注度的增速，Rust 无疑是 2021 年最吸睛的编程语言。尤其是在 2021 年 12 月，Linux 内核和 Rust on Linux 的主要开发者 Miguel Ojeda 向 Linux Kernel 邮件列表提交了一个新补丁 (v2)，进一步推进了 Rust for Linux 的工作进展，将公众对 Rust 的关注推向了新的高潮。

Rust 最重要的优势在于以媲美 C/C 的性能表现，解决了编程过程中的内存安全问题，从而成为各团队在系统级编程领域的重点调研对象。

C 问世四十年，相关方法技巧已经成熟，催生了编程大神无数，但在 2021 年的今天，我们仍然在寻找其替代品。其根本原因在于，人们逐渐明了，性能并非系统级编程语言的全部，随着软件逐渐接管 IoT 设备（尤其是自动驾驶车辆），内存溢出 / 指针悬垂类的内存安全问题，已经不只会造成经济损失，更会威胁人身安全。与其面向结果，出了问题再改 Bug，不如面向过程从一开始就把控好内存安全。

但 Rust 的上手难度，又在一定程度上，制约了语言本身的普及（知乎有一吐槽：为什么用 Rust 实现链表都这么难）。了解函数式编程或对学习 Rust 有所帮助，但编程世界未来的主流仍将是 OOP（面向对象程序设计）。更大的问题在于中小型公司的替换成本 —— 不存在成熟的人才梯队，不存在坚实的技术积累，直接采用 Rust 面临的问题是：无人可招。当下，几乎所有准备采用 Rust 的公司都是大型公司或创业团队，前者可以通过内部转岗积累人才，后者则从一开始就是围绕 Rust 构建的创业 idea。

相比性能与安全，研发效能在今天反倒成为了一个模糊问题。狭隘地说，选择一门学习门槛低，开发效率高的语言，就是提升了研发效能；站在更大范围、更长的时间尺度来看，选择一门性能满足研发需求、生态成熟、内存安全有保障的语言，也是提升了研发效能；选择社区够完善，招聘难度低的语言，方便快速组建研发团队，也是变相提升了研发效能。

那么，在 2021 ，一个研发团队应该如何选择适合自己的编程语言？在保证了性能需求和安全需求后，则需要结合业务场景、公司发展阶段具体分析了。

八仙过海，承诺兑现

除通用型语言外，如果要用四个字形容 2021 年各家垂直领域语言的发展，那么恐怕是“八仙过海”了。垂直领域用特定语言解决特定问题的趋势越发明显，语言的“工具”属性愈发突出。

在移动端开发，Kotlin 独树一帜；在数据科学领域，Python 和 R 语言应用甚广；在 Web 端，有越来越多的人开始尝试使用 TypeScript。但需要注意的是，当下所谓的 xx 领域专用语言，或许到了 2022 年，就会产生天翻地覆的变化。如果细细琢磨，你可能会发现，这种变化正在发生，比如 Kotlin、Julia。

WebAssembly 是其中比较另类的存在，它致力于让其他语言都能以接近原生语言的速度在 Web 端运行，目前最主流的应用是将 C/C 编译为 WebAssembly。其在 2021 的具体进展，我们在接下来的“2021 主要编程语言的具体发展”中单独讨论。

同时，编程语言也在兑现给开发者的无数承诺，那些在社区内早有风声的前瞻性修改，在 2021 最终完成了“填坑”。

2021 代表性编程语言的发展概况

（关于 Go、Rust、Julia 的更多内容，可额外参考本次盘点特别策划部分，文章链接详见附录）

Go

说到“填坑”，2021 当数 Go 语言最得人心。作为编程语言界最近几年最受欢迎的一员，Go 却长期存在三个主要问题为开发者所诟病，即：模块管理工具、泛型语法支持，以及程序错误的处理方式。

关于模块管理工具，Go 语言开发团队基本已经解决或给出路径；对泛型的支持，相当于有了定论；错误处理方式还未找到妥善的解决办法。而 Go 语言的 2021 主要动态，也是围绕着模块管理工具和泛型展开。

GO111MODULE 是个系统环境变量，目的是方便开发者们在原始的 GOPATH 机制和新的 go module 机制之间做切换。Go 团队在 1.16 版本中把 GO111MODULE 的默认值设置为了 on ，这标志着 go module 机制的成熟。同时，这也说明 Go 团队已开始正式普及 go module 机制。

从 Go 官方提供的标准工具来看，原有的那些 go 命令都已经完全适配了 go module 机制。比如，go get 命令现在可用于调整 Go 模块的依赖关系，go install 命令现在可用于下载、编译和安装 Go 模块， go test 命令现在也可用于编译并测试 Go 模块，等等。

围绕模块管理中的配置文件，另外有三点值得注意：

• 模块图修剪：在 go.mod 文件中，针对主模块的直接依赖模块记录和间接依赖模块记录已变得完整；
• 新的指令：在 1.16 版本中，Go 团队为 go.mod 文件增加了一个新指令。这个指令的名字叫做 retract。我们在这里可以把它理解为“撤回”，用于撤回当前模块的某个已发布版本；
• 新的注释：在 1.17 版本中，Go 团队为 go.mod 文件增设了 deprecation 注释，用来废弃整个模块。

对泛型的支持，最早要追溯到 2018 年，但直到 2021 年 8 月，Go 团队才放出了一个终极的设计方案：Type Parameters Proposal（https://GitHub.com/golang/proposal/blob/master/design/43651-type-parameters.md） 。至此，一个紧密贴合了 Go 语言的泛型模型才算正式出炉。Go 语言的 1.17 版本中已经包含了一些与自定义泛型有关的代码，不过要想自由地使用泛型，则要等到 1.19 甚至更远的版本了。

除此之外，2021 年，Go 在标准命令、标准库、语法、性能方面都有更新，我们这里简单列举，作为参考：

标准命令：

1. 在 1.16 版本，Go 官方对 go install 命令进行了改进，使它可以接受一种版本后缀（如：@v1.0.0），并以此来下载、编译并安装（以下统称为安装）某个代码包的特定版本；
2. 从 1.16 版本开始，Go 官方推荐开发者在 go module 机制下只使用 go install 命令来安装代码包，并强烈建议，在使用 go get 命令的时候应该携带 -d 标记；

标准库：

1. 新增三个代码包：runtime/metrics 包（获取运行时指标，涉及垃圾回收、内存使用、并发调度等）、io/fs（代表了一种全新的文件系统模型）、embed（在可执行文件中嵌入额外的资源）；
2. 废弃 io/ioutil 包；

语法：

支持从切片到数组指针的转换。更具体地说，类型为 []T 的切片现在可以被正确地转换为以 *[N]T 为类型的数组指针了；

性能：

1. 在 64 位的 Linux 操作系统上，其链接速度比 1.15 版本快了 20%-25%，同时链接操作所占用的内存空间也减少了 5%-15%。此外，由于更激进的符号修剪，Go 程序经处理后产生的二进制文件通常也更小了。
2. 在 1.17 版本中，Go 团队实现了一种使用寄存器而不是堆栈来传递函数参数值和结果值的新方法。这一新方法让 Go 程序的运行性能提升了大约 5%。并且，Go 程序产出的二进制文件通常也会小 2% 左右。目前，在 Linux、macOS 和 Windows 操作系统的 64 位计算结构上，Go 语言都自动启用了此功能。

Rust

2021 ，Rust 的热度丝毫不逊于 Go 语言，但本次盘点特约专家张汉东有一句话说得很好：“Rust 的出现不是为了重写这个世界已经存在的一切，而是为了让未来更加美好。”

对于当下本就关注度极高的 Rust 来说，分外适用。

2021 年，Rust crates 的下载总量达到 11,012,362,794 次，即 110 亿次。

伴随着下载量的增长，Rust 语言内存安全初步成果也已经显现。据 2021 年 12 月 31 日发布于 arXiv 的论文 《SOK: On the Analysis of Web Browser Security》中所言：

比较了四种浏览器架构，以及近十年来浏览器中内存安全问题依然是主流，比如 Firefox 就通过 Oxidation 项目（Rust）替换了 12% 的组件。自 2015 年以来，Firefox 的内存安全漏洞数量出现了小幅但稳定的下降，其中，渲染器的内存安全漏洞明显下降。

Oxidation 是专门用于将 Rust 代码集成到 Firefox 中的一个项目。Firefox 54 以来，所有平台都需要 Rust 支持，并且第一个主要的 Rust 组件是在 Firefox 56 (encoding_rs) 和 57 (Stylo) 中发布的。展望未来，Oxidation 的目标是让在 Firefox 中使用 Rust 变得更容易和更高效，并相应地增加 Firefox 中的 Rust 代码量。

可以说经过六年的应用，Rust 语言的内存安全保障终于看到了初步的效果。该论文建议浏览器供应商遵循这一最佳实践，并逐步将他们的浏览器转向内存安全的语言。

Rust 语言及相关生态在 2021 年一些看点简单罗列如下：

• Rust 编译器引入了一个新的实验性 GCC 后端，以及另一个基于 gcc 的实现（目前两者都在进行中）。
• Rust 正在进入 Linux 内核，这也为语言和库带来了一些改进以促进这一壮举。
• Rust 首次进入 Redmonk 指数前 20 名 ，并连续 第六年获得 Stack Overflow 调查的“最受欢迎的编程语言”桂冠。
• IEEE 2021 编程语言排行榜，Rust 排 17。按趋势来排，Rust 在第十位。
• 2021 年初 Rust 基金会刚成立，到年末，已经有二十五家来自不同领域并且有一定建树的成员。并且基金会也开始落实一些具体安排，比如组织专业的 crates.io 运营。
• 瑞士 Concordium 基金会宣布 DevX 计划，将赞助 Rust 生态的维护者们。
• Espressif （乐鑫）正式雇佣 mabez 针对 eso 芯片开发 Rust 支持：esp-rs。
• 嵌入式 Rust 生态得到长足发展：嵌入式并发框架已经 1.0 、嵌入式异步框架正在大力开发且支持 STM32，nRF 和 RP2040 平台，并且还深深影响着 Rust 异步的改进、嵌入式开发和调试工具又发布了新的探针工具、嵌入式 smoltcpTCP/IP 栈发布了新版本、嵌入式图形库 Matrix 发布了新版本、新的嵌入式实时 OS Hubirs 开源。
• WebAssembly 领域。前文提到的字节码联盟的 wasmtime 的 Cranelift 编译后端完成了新的后端架构更改，还得到了 IBM 大型机的支持而引入了新的 s390x 后端。有两个和 Rust 相关的 Wasm 项目进入了 CNCF ：WasmEdge 和 WasmCloud 。
• 图形计算领域：rust-cuda 和 rust-gpu 这两个项目，为推动 Rust 成为 GPU 计算第一语言开始发力。前者是将 Rust 作为 GPU 第一语言，后者则推动 Rust 成为图形渲染第一现代化着色语言。
• 国内 Rust 职位招聘有所增长：字节跳动、海致星图（图数据库）、非凸科技（量化）、达坦科技（分布式存储）、Datebend（数据仓储）都大量需要 Rust 人才。
• GUI 领域的 SixtyFPS 和 tQCS 这样的咨询公司建立了合作关系，找到了第一个客户，招募了新成员。tQCS 提供世界 No.1 的 Qt 咨询和 UI/UX 设计服务，选择和 SixtyFPS 合作，这也算是 Rust 在 GUI 领域的一个里程碑。
• Embark Studios 发布了它们公司第一个 3A 游戏，在其游戏后端也用到了 Rust 。Embark Studios 是 Rust 游戏工作组的成员之一，致力于将 Rust 推广到游戏开发中。rust-gpu 库就是他们开源的项目之一，并且该公司也赞助了很多游戏和图形学相关的 Rust 生态库。
• Rust 在 音视频领域也得到了应用，Signal 公司使用 Rust 开发了支持 40 人高质量语音群组通话的服务。
• Rust 也成为前端基础设施的一员：Next.js 公司用 swc 和 Rust 完全取代 Babel（transpilation）和 Terser（压缩）。

就版本更新而言，Rust Edition 现在已经确定了 —— 每三年发布一个版次。这就意味着 Rust 每三年都会围绕一个引领 Rust 发展的主题。

2021 Edition 的主题是「成熟（Mature）」。2021 edition 并没有引入太多新特性，而是清理了一些技术债务，比如持续对 Rust 编译器进行重构和改进，包括内部使用的新的 trait 系统 chalk 和 query 系统（开源版本：https://github.com/nikomatsakis/salsa）。另外还处理了一些向后兼容的问题，以及持续投入一些影响未来发展的关键特性，比如 常量泛型、泛型关联类型等。

前文我们也提到， Rust 今年的一个重要动态就是对 Linux 内核的支持。到 2022 年，我们很可能会看到 Linux 内核中的实验性 Rust 编程语言支持成为主流。而在 2021 年 12 月 6 日早，Rust 团队发出的更新的补丁中，则介绍了在内核中处理 Rust 的初始支持和基础设施。

这次更新的内容包括：

1. 升级到了最新 Stable 编译器和 Rust 2021 edition 。因此可以摆脱了 const_fn_transmute，const_panic、const_unreachable_unchecked、core_panic 和 try_reserve 这几个之前未稳定的特性。
2. 自定义 core 和 alloc。为 alloc 添加了更加模块化的选项，以便禁用一些他们不需要的功能：no_rc 和 no_sync，主要是为上游 Rust 项目添加。
3. 更严格的代码、文档和新的 lint。
4. 抽象和驱动程序更新。添加了序列锁、电源管理回调的抽象，io 内存（readX/writeX）、irq 芯片和高级流处理程序，gpio 芯片（包括 irq 芯片）、设备、amba 设备和驱动程序以及证书。此外，也改进并简化了 Ref（refcount_t 支持）对象并用它替换了 Rust 的 Arc 的所有实例。完全地从 alloc crate 中删除了 Arc 和 Rc。

从现在开始，Rust for linux 团队将开始定期提交补丁，每两周左右。

关于 Rust，还有一点不得不提，那就是发生在年末的审核团队（mod team）集体离职事件。但当尘埃落定，事件本身的性质已经不好评价，涉及美国独有的政治、文化及种族问题。张汉东在采访中说道：

“2020 年 Rust 1.44 版本发布时，官方博客说过这么一句话：「tech is and always will be political」。对于美国文化不太了解的我，之前还对审核团队存在的重要性嗤之以鼻，现在感觉审核团队的存在对于 Rust 这样深处文化政治复杂的美国是多么重要。我终于理解 Rust 官方团队所说这件事的背景相当复杂的原因了。真心希望 Rust 团队能处理好这件事。对此，我们能做些什么呢？也许只能祈祷世界和平。”

Kotlin

2021 年刚好是 Kotlin 10 周年，在这一年里，Kotlin 共发布了 1.5 及 1.6 两个版本，目前最新版本为 Kotlin 1.6.10。如果要将其中的关键动态总结一下，那么会分为如下四点：

• K2 编译器：目标是全新打造的编译器架构，提供更好的性能并为多平台发展建立良好的基础。
• Kotlin Multiplatform Mobile（KMM）持续更新，预计在 2022 年春天发表 Beta 版本；
• Kotlin/JS：新的 IR 编译器发表 Beta，更多 JS 库迁移到新 IR 编译器；
• Compose Multiplatform 1.0：可用于 Desktop 和 Web 的声明式 UI 框架，对安卓开发者来说，更容易从 Jetpack Compose 切入；

K2 编译器是 Kotlin 在 2021 年最重要的更新。编译器分为前端和后端，功能包含生成语义信息的 IR （中间表示），并转为相应目标平台（JVM、JS、Native）的可执行文件。Kotlin 1.5 版本就已经开始支持 K2 编译器，目前 Kotlin/JVM 已是稳定版本，Kotlin/JS 是 Beta 版本。

Kotlin 的开发生态圈非常活跃，目前 Kotlin 团队共有约 100 位开发人员，超过 360 位开源贡献者参与开发工具，2021 年约有 25 万个与 Kotlin 有关的代码仓库在 GitHub 上被创建出来。

有两份报告可供我们参考：

开发人员及开源贡献者数据：

https://kotlinlang.org/lp/10yearsofkotlin/present/

Kotlin 开发生态系调查：

https://www.jetbrains.com/zh-cn/lp/devecosystem-2021/kotlin/

而 2021 年， Kotlin 整个生态的活跃，也从侧面印证了这些官方团队和开源贡献者的工作成果。生态进展如下：

JetBrains 方面：

• UI 框架：Compose Multiplatform 1.0
• Server-side：Ktor 2.0 beta，Kotless 0.2.0
• Data Science 及 ML：Kotlin API for Spark，Kotlin DataFrame library，KotlinDL
• 工具：Dokka 1.6（文档引擎），Kover（代码覆盖率），Qodana（静态分析器）

社区方面：

• Spring Native
• Arrow (Kotlin library for functional programming) release 1.0
• Koin (dependency injection framework) release 3.0
• KorGE (Game engine) release 2.0
• Okio (I/O library for Kotlin Multiplatform) release 3.0
• Apollo (GraphQL client) release 3.0

此外，Kotlin 也很重视中国开发者的生态建设，2021 年，他们与 Kotlin User Group 合作，举办了中文开发者大会，吸引了 1500 观众参加。

Kotlin 2022 年的发展重点可以总结为如下四点：

• 持续发展 K2 编译器：优化性能、编译速度及支持插件的能力
• 改善开发者体验：优化 Kotlin IDE 插件，提升稳定度及性能，让修改、测试除错循环可以更高效
• 深化支持 Kotlin 在 Server-side 的应用：更多是 Spring 及 Ktor 方面的应用
• 推出新版 Kotlin Multiplatform Mobile（KMM）：预计在 2022 年春天推出 Kotlin Multiplatform Mobile Beta，并持续改善共享代码的开发体验

（具体路线图可参考：https://kotlinlang.org/docs/roadmap.html）

而在这背后，是 Kotlin 积极地向多平台语言演进的努力，用本文的话语体系来讲，就是“通用型语言”。我们可以看到 JetBrains 提供了多个支持多平台的库如 kotlinx.coroutines，kotlinx.serialization，kotlinx-datetime，而 Kotlin 社区也紧跟着这样的趋势发展，出现了愈来愈多的库、框架来支持多平台，如 Arrow、Okio、Apollo 等在新版本中都支持了多平台开发。

令 Kotlin 社区工作者苦恼的是，自 2017 Google 发表声明后，Kotlin 总被当成是安卓专用开发语言。实际上，Kotlin 极有可能在接下来的两个领域成为主流编程语言：

• Desktop：设计 Kotlin 的初衷就是要拿来开发 IntelliJ IDEA，随着 Compose Multiplatform 的发布，使用 Kotlin 开发 Desktop 软件将更加轻松；
• Server-side：Kotlin 100% 与 Java 互操作的特性让许多 Java Server-side 开发者转而使用 Kotlin，现也有 Spring 官方的支持及 JetBrains 推出的 Ktor 框架，使用 Kotlin 开发 Server-side 应用将有机会成为主流。2021 年 使用 Kotlin 做 Server-side 开发的用户提升了 40%，可见其潜力；

同时，Kotlin 对 WebAssembly 的支持工作也提上了议程，未来也将成为 Web 端编程语言的可选项之一。

就这一点而言，我们倒不妨大胆畅想 Kotlin 2022 年的发展态势，看其在未来几年内，能否重现当初 Objective-C 两夺年度最佳编程语言的盛况。

Julia

在刚刚过去的 2021 年，Julia 编程语言社区依然保持了高速发展。据统计，目前 Julia 的全球总用户量已超过一百万，有一万多家公司和一千五百多所高校下载和使用了 Julia。此外，一些世界名校，如北京大学，MIT、Stanford 和 Berkeley 等，已经在教学中使用 Julia 语言。Julia 默认的注册表中新增了 1128 个包，累计达到了 5397 个。详细的信息可以前往 JuliaHub.com 查看，获取各个库下载信息的方法也已在官方论坛中公布。

2021 年，Julia 发布了两个重要版本，分别是 Julia@v1.6 和 Julia@v1.7。此外，在 Julia@v1.7.0 于 11 月 30 日发布的同时，社区正式宣布 Julia@v1.6 为新的长期支持版（LTS）。Julia 官方博客中详细介绍了 Julia@v1.7 的一些新特性，这里我们列出尤其值得关注的几点：

1. 全新的多线程特性：解决了许多运行时的竞态条件，优化了多线程之间任务的调度，同时让默认的随机数生成器对多线程更加友好，此外还新增了一类原子操作作为基本的语言特性；
2. 包管理的更新：新版的包管理工具会自动识别出该包是否已经注册，如果是的话，则会提示你是否要自动安装；
3. 对 Apple Silicon 的支持：Julia@v1.7 是首个能运行在 Apple Silicon 上的版本，但对该平台的支持还仅处于 tier 3 (即仅处于实验性质，编译 / 测试有可能失败)；
4. BLAS/LAPACK：运行时的后端切换；
5. 编译延迟和运行时体积优化；
6. 更好的类型推断、代码分析和检查；

而在社区和生态方面，Julia 的进展和动态极多。关于社区，我们尚可简述重点：FluxML 社区于 12 月 1 日正式宣布挂靠在 NumFocus；JuliaComputing 完成 A 轮融资。

以及国内镜像站进一步增加，包括：

• 北京外国语大学 （https://mirrors.bfsu.edu.cn/julia）
• 清华大学 （https://mirrors.tuna.tsinghua.edu.cn/julia）
• 上海交通大学（https://mirrors.sjtug.sjtu.edu.cn/julia）
• 中国科学技术大学 （https://mirrors.ustc.edu.cn/julia）
• 南方科技大学 （https://mirrors.sustech.edu.cn/julia）
• 南京大学 （https://mirrors.nju.edu.cn/julia）

但关于生态，以及 Julia 在行业内的实践，则受限于篇幅，需要你移步附录中的特别策划了。总的来说，Julia 的发展和 Kotlin 有共通之处，都在由特定领域的专用语言，转而向多领域通用语言发展。

WebAssembly

于 WebAssembly 而言，2021 年发生了一件大事。

就在 2021 年的 10 月， Photoshop 发布了 Web 版本，大量使用了 WebAssembly。Photoshop 是传统的巨型桌面软件，代码库完全基于 C 编写。这次成功发布 Web 版本，验证了大型、高复杂度、基于传统高级语言编写的软件，是完全可以通过 WebAssembly 运行在 Web 端的。

而在区块链智能合约领域，WebAssembly 因为对 Web 的兼容，且允许使用 C 、Rust 编写高性能程序，已成为事实上的王牌语言。在 IoT、可信计算、轻量级容器等领域内，WebAssembly 都有十分契合的特性。这让开发者群体对 WebAssembly 的关注度迅速增长。

2021 年，WebAssembly 语言技术值得关注的发展包括：

1. WebAssembly 开源项目开始支持 GC（垃圾回收器），为实现 WebAssembly 支持像 Java、Kotlin 这样的前端语言做准备；
2. WebAssembly SMID 可变长度取得关键进展，帮助 WebAssembly 应用充分获得 CPU 向量化计算加速能力；
3. WebAssembly 模块化取得关键进展，为进一步构建 WebAssembly 的生态提供了核心的支撑；
4. 源码调试能力的增强，WebAssembly Micro Runtime 和 WASMTIME 等开源项目都提供了源码的调试能力，极大促进应用开发的效率

另一个重要动态是“字节码联盟（Bytecode Alliance）”正式成为了非营利性实体组织，致力于开发基于 WebAssembly 和 WASI 的安全开源软件栈，建立一个默认安全的 WebAssembly 生态系统，让应用程序开发人员和服务提供商能够自信地在任何基础设施、任何操作系统或设备上运行不受信任的代码。字节码联盟发展十分迅速，其成员包括 Fastly、英特尔、微软、Google、Amzaon、Arm、 西门子等企业。业界普遍期望字节码联盟可能会更有效率地推进 WebAssembly 的更新和迭代工作。

更多的编程语言，如 Python、Swift……我们难以在同一篇文章中全部盘点，只能寄希望于 2022 年，我们继续关注编程语言领域的核心动态。相信在 2022 ，各大编程语言也会为开发者带来新的惊喜。

附录：2021 编程语言盘点特别策划及 Java 2021 部分动态盘点

解读 Julia 的 2021：逐步迈向主流编程语言：https://url.cy/Sr7oU1

解读 Go 语言的 2021：稳定为王：https://mp.weixin.qq.com/s/9LKyPfhwldgZY7H4iS7sjg

解读 Rust 的 2021 （上）：https://mp.weixin.qq.com/s/aTCogUxyUwE6Sa4Nfs9CYA

Java 2021 部分动态盘点：https://www.infoq.cn/theme/125