相比高人气的 Rust、Go，为何 Java、C 在工具层面进展缓慢？( 二 ) _Rust

——Amir Saeid

所谓标准库，就是语言所附带的常用内容库。C 有 libc、C++有 libcpp，但与如今常见的内置“电池”标准库相比，前面二位的库规模实在小得可怜。

我有点记不清了，但 1991 年诞生的 Python 似乎是第一种真正拥有广泛标准库的编程语言。Java 1.0（1996 年）也附带一个扩展标准库（Java Class 库），随后引发其他语言纷纷效仿。

这种无需自行构建、又不必接触第三方依赖项的便捷工具交付方式，实在是全世界开发者的一大福音。

标准库中的佼佼者：GoLang
大部分现代语言（不包括 JavaScript ）现在都附带丰富的标准库。不过，Go 对标准库的强调仍然无人能及，它承诺向下兼容，而且非常关注性能和完善的具体实现。正因为如此，Go 开发者对标准库的依赖性远超其他社区，对标准库也普遍更为重视。

第三方工具包库
就在标准库成形的同时，万维网也开始迅速腾飞。事实证明，互联网确实是一套出色的协作平台。

如果我们的需求无法在标准库中得到满足、必须自行构建新功能，该怎么做？Perl 通过 CPAN 推广了全球工具包集合的概念，一切就从那时起彻底改变。公平地讲，任何用过 CPAN 并为它做出贡献的朋友，都能感受到它改变游戏规则的重大意义。

CPAN 于 1995 年推出（基于 CTAN），并于 2003 年达到顶峰。它的出现为使用软件完成工作的人们开辟出一条新的路径，就是将第三方组件拼接起来。现在，很多现代开发项目都会遵循这种模式。

从 2003 年开始，之后诞生的常用编程语言几乎全部附带某种第三方工具包库。这股风潮的缔造者就是 CPAN，它告诉全世界：“真正的”编程语言，必须要有第三方工具包管理策略。

旁注：向后移植
说到这里，有朋友可能会问，既然 CPAN 让 Perl 变得更好、也让后来的新语言都接受了第三方工具包管理器这个概念，那为什么之前的语言就没想着亡羊补牢、加上包管理器呢？

其实他们有想过，但语言的发展一旦经过特定阶段，之后再想达成一致意见似乎变得越来越难。我不知道为什么会这样，可能大多数人不喜欢做改变？

反正只要编程语言的习惯表达、基本模式和技术社区一旦建立，就很难再回头调整了。正是因为这个，所以 JavaScript 有 NPC、Rust 有 crates，而 C++却自己独占 dds、cpm、conan、pacm、spakc、buckaroo、hunter 和 vcpkg 。就是因为达不成普遍共识，所以 C++这边才冒出了八种工具包管理器。

但标准库的向后移植倒是比较顺利，C++成功把一部分 STL 招至麾下，虽迟但到底完成了标准库的添加。所以说，老语言也可以搭载工具创新，只是难度会更大一些。

总之，在 CPAN 之后，强大的标准库已经能帮助开发者完成大部分任务。另外，易于使用且接受直接贡献的第三方工具包库也成了标配。没有这两样，语言将毫无生命力。

文档支持

文章插图

有了第三方工具包，接下来就是用简单的方式把它们记录下来。我遇到的最早文档版本就是 Javadoc 。它让我能更轻松地在 Java Class 中找到自己需要的内容：只需在 Web 上的 Javadocs 中单击即可。之后，我们可以把 Javadoc 和 IDE 集成结合起来，快速使用自己之前从未见过的代码。由此，探索性编码成为了可能。

最强的文档工具：Rust 的 docs.rs
如今，Java 的 Javadocs 已经不再是业界标杆。Go 有 godoc，Julia 有 Documeter.jl，就连 hackage 也有很好的工具包文档。但纵观天下，最强的文档工具还要数 Rust 的 docs.rs 。

一次编写，随处运行

我看到的一项改进是，J2EE 和 Web 服务器的标准化，成就了我们今天赖以生存的计算基础。Java 与 JVM 虽然做出开创，但我觉得它们并没得到充分的认可。在 Java 普及之后，开发平台与部署平台真正实现了互不干扰。如今每个人都习惯了这样的优势，但在 20 年前，这绝对是场革命性的颠覆。
——Cédric Beust