在编程语言的激烈竞争中，Rust 凭借出色的安全性、高性能与现代化的语法迅速崛起，成为系统编程领域一颗耀眼的新星。它的成功不仅改变了人们对系统编程语言的传统认知，也在整个行业内激起了关于语言设计的新一轮思考。而在这份成功的背后，站着 Jim Blandy 这样的开源先驱。

Jim Blandy 是《编程 Rust》（Programming Rust）的作者，自 1990 年起便投身开源项目。大学毕业后，他与自由软件运动的先驱 Richard Stallman 共事，后来成为 GNU 调试器与 Emacs 的核心维护者之一，也是 Subversion 项目最初的设计者之一。

Rust 诞生时，Jim 与它最初的设计者 Graydon Hoare 已是多年好友。在那之前，Jim 一直认为 C 和 C++ 已经触及了系统编程语言的天花板，不可能再有突破。而 Rust 的出现彻底颠覆了他的判断——他从未想过，一门语言在放弃了指针操作的灵活性之后，竟然还能如此高效且易用。他当即意识到，自己必须写一本关于 Rust 的书，把这场伟大的革新记录下来。

Jim Blandy 亲历了开源软件的崛起与变迁。他认为，自由软件运动最大的成就，是让开发者把“使用自由的工具”视为理所当然，不再接受专有软件的种种限制。带着对编程语言的深刻洞察与对自由软件始终如一的坚持，Jim Blandy 与 CSDN 资深技术编辑王启隆（Eric Wang）展开了一场深入对谈。在这次独家专访中，他分享了自己对 Rust 的理解、对自由软件运动的信念，以及对开源软件未来的展望。

对话亮点：

  • 有人认为自由软件运动已经死了，我完全不同意。在我看来，自由软件运动最大的成就，就是开发者如今理所当然地认为，自己使用的工具就该是自由的。

  • 我曾以为 C 和 C++ 已经是系统编程语言的极限，不会再有突破了。我从没想到，在放弃了指针操作的灵活性之后，一门语言还能这么高效、这么好用。我当时立刻意识到，我们必须写一本书，把这场伟大的革新记录下来。

  • 我确实认为 VS Code 接过了 Emacs 的衣钵，成为了 Emacs 精神的继承者。

  • Rust 的一条核心限制，是它不允许“共享”与“可变”同时存在。

  • 他总结说：“当 Rust 的借用检查器闻到烟味时，那一定是真的着火了。“这让我意识到，C 语言里的灵活性未必总是好事，Rust 的严格反而能帮开发者避开错误。

  • 我确实觉得 Emacs 有点过时了——当然，也许过时的是我自己。我会一直用 Emacs，用到最后一天。

1. 开源先驱：记录 Rust 的诞生

Eric Wang: 能否请您介绍一下自己，以及《编程 Rust》这本书？

Jim Blandy: 从 1990 年起，我就一直参与自由软件和开源项目。大学毕业后我与 Richard Stallman 共事，之后开始参与 GDB 的开发，成为 GNU 调试器和 Emacs 的核心维护者之一。我也是 Subversion 项目最初的设计者之一，尽管 Subversion 如今已逐渐过时。我还记得第一次用 Mercurial 的情形——相比我们一直在用的版本控制系统，Mercurial 在性能上是一次巨大的飞跃，在我们在意的每个方面都表现优异。所以我决定从 Subversion 转向 Mercurial。

2008 年起我在 Mozilla 工作，参与了浏览器开发的多个部分，包括 JavaScript 引擎、调试器、开发者工具，以及现在的 RDP 实现。也正是这段时间，我和 Jason Orndorff 合作写了一本书。

Rust 诞生的时候，我和它最初的设计者 Graydon Hoare 已经是朋友了。我们曾在 Red Hat 共事，后来他加入 Mozilla，又邀请我一起去。他告诉我，他正在设计一门新的编程语言——Rust。我非常感兴趣，迫不及待想试一试。当时的 Rust 还是一门非常特别的语言，Graydon 更倾向于为了更好的语义设计而在性能上做一些让步。而今天的 Rust 已经发展成一门严格而高效的系统编程语言，能产出质量极高的代码，与 C++ 竞争也毫不落下风。

这并不是 Graydon 最初的设想，但 Rust 1.0 的发布让我们所有人都非常兴奋。Graydon 最在意的问题——安全性——被 Rust 解决了，它成了一门真正安全的系统编程语言。这让我非常震撼，因为我原本认为 C 和 C++ 已经是系统编程语言的极限，不可能再有突破。而 Rust 的出现击碎了这个认知。

Rust 通过独特而严格的内存管理模型，获得了相对 C 和 C++ 的安全优势。但这是有代价的——你必须放弃一部分灵活性。要换取 Rust 提供的安全与可靠，就得牺牲一些表达力。我从没想过，在放弃指针操作的灵活性之后，还能有一门像 Rust 这样既高效又好用的语言。所以当我看到 Rust 的这些特性时，我立刻意识到，我们必须写一本书，把这场伟大的革新记录下来。

Eric Wang: 这本书的第二版是怎么来的？写了多久？

Jim Blandy: 写第二版对我来说并不轻松。有人可能觉得写作是件简单的事，但对我而言它始终充满挑战。我总担心自己再怎么努力，结果也不够理想。写作其实是一个发现自己认知盲区的过程——当你试图把想法落成文字时，常常会发现有些东西自己并没有真正弄懂。

这个过程可能相当令人沮丧，尤其是在交稿期限逼近的时候。那种感觉就像：“等等，也许我根本不知道自己在说什么！“遇到这种情况，我只能暂停写作，去做一些实验，写一些有意思的程序，真正吃透那些概念之后再继续。只有那时我才有底气把它写出来。写作的压力相当大，这也是第二版拖了挺久的原因之一。

第一版是我和 Jason 一起写的，第二版则只有我和 Nora 两个人。到了第三版，我把最初的几位作者都请了回来，希望大家能互相帮助、互相激发、互相鼓励。这种协作的方式很有意义，也让我们对第三版充满期待。

Eric Wang: 第三版会加入图形编程的内容吗？

Jim Blandy: 我们正在写第三版，O’Reilly 希望能在 2025 年出版，我们会针对第 25 版的 Rust 做修订。在着手下一版时我们意识到，挑选合适的示例是整个写作过程中最困难的部分之一。

这本书的一个关键特点是：在用示例讲解语言概念时，示例本身不能过于复杂，也不能分散读者的注意力。否则读者会连示例在做什么都难以理解，更别提借它理解 Rust 的真正用法了。而图形编程充满了各种古怪和意料之外的细节，因此很难找到既有教学价值、又不喧宾夺主的内容。

在我看来，图形方面的内容还没有达到“既有教学价值，又足够吸引人”的标准，不足以有效地讲授 Rust 的语言概念。我很想把两者结合起来，但这本书的重心永远是“教学”。有人可能会说这不就是文档吗——我必须澄清，它不是文档，它是讲解。这本书的目标是教会读者，为他们理解文档打下基础，提供基本的概念、框架和动机。所以我们必须始终聚焦在教学上。

Eric Wang: 书中您把 Rust 与 C、C++ 做了对比。Rust 如何改变了您对系统编程语言的看法？

Jim Blandy: 在 Rust 出现之前，我认为系统编程领域已经没有太多改进空间了。系统程序员的核心任务是掌控机器资源，他们需要能够预测生成代码的行为，理解数据在内存中的表示方式。这种对底层控制的需求，让 C 语言的设计显得几乎是必然的。但 C 用起来可能很困难，在大型项目中尤其如此。

后来出现了 C++，它试图通过引入泛型之类的特性来弥补 C 的不足。但我当时认为，语言设计上已经没有多少更好的空间了。然而 Rust 的出现改变了我的看法。它让我意识到，在语言设计上我们其实有很多选择，而 Rust 的独特之处在于，它给出了一个既安全又实用的方案。

事实上，设计一门安全的语言并不算难，真正的挑战是设计一门既安全又实用的语言，而 Rust 做到了。让我印象深刻的是，Rust 的安全特性其实是一个独特的子集，但它几乎覆盖了系统编程所需要的一切。

我有一位非常出色的程序员朋友，他是 GNU Grep 最初的作者之一。GNU Grep 发布时，整个 Unix 社区都很兴奋，因为它比同类工具快得多。Rust 刚出现时，他说自己不会用 Rust，因为他经常和图打交道，而 Rust 不允许创建循环引用，他无法接受这个限制。我能理解他。但后来我开始用 WGPU 时发现，Rust 的这些限制并不构成问题——它在忠于自身开发模型的同时，依然提供了出色的性能。这让我意识到，Rust 的限制其实是一种优势，它们能帮开发者避开潜在的错误。

Rust 的一条核心限制，是它不允许“共享”与“可变”同时存在。如果一份数据被多个线程访问，那它必须是不可变的；如果你需要修改它，就必须确保没有别的线程能访问它。这个限制是严格了些，但恰恰是它让 Rust 与众不同。

我的合著者 Jason Orndorff 有个爱好，喜欢把简单的 C 程序用 Rust 重写一遍。他发现大多数时候转换都很顺利，但偶尔会遇到无法直接翻译的代码，而这些 C 代码里往往藏着潜在的 bug。他总结说：“当 Rust 的借用检查器闻到烟味时，那一定是真的着火了。“这让我意识到，C 语言里的灵活性未必总是好事，Rust 的严格反而能帮开发者避开错误。这也让我开始怀疑，我们是否真的用好了那份额外的自由。事实上，C++ 程序被正确写出来的比例，可能远比我们以为的要低。最终，时间会证明一切。

2. 自由软件运动从未死去

Eric Wang: 作为一位把整个职业生涯都投入自由软件运动的开发者，您认为这场运动这些年来最大的成就和挑战分别是什么？

Jim Blandy: 我变得更乐观了。我的一些朋友认为自由软件运动已经死了，但我完全不同意。在我看来，自由软件运动最大的成就，就是开发者如今理所当然地认为，自己使用的工具就该是自由的。而在我们刚起步的时候，这远不是一种普遍的期待。当时软件被视为一门生意——你要用某个软件，就得付钱，而开发者必须限制用户的自由来确保他们付费。当然，这里的“自由”指的是 freedom，不是价格。这是我想强调的。

过去人们觉得只能接受专有软件的模式，但这种心态如今已经改变了。GitHub 就是个很好的例子。它的核心使命是推动开源软件，为开源项目提供基础的工具和资源。GitHub 本身虽然不是开源的，但它为许多有趣的作品提供了巨大的支持。对我来说，最重要的变化是人们看待自身需求的方式变了。人们现在相信，自己有权获取源代码、使用自由的工具、提交 bug 报告、参与开发过程。如果事情没有按他们希望的方向走，他们甚至有权把它“拆开重来”。这些信念已经深深植根于整个行业，我们无法回避。

那些对开源持悲观态度的人，往往会盯着像 Linux 内核这样的项目。Linux 内核无疑是开源领域的巨大成功。用的人越多，它的使用就越广泛，在技术市场中的地位也就越稳固。对 Google 来说，Linux 至关重要；对微软来说同样如此。微软对开源的态度在过去十年里发生了戏剧性的转变，主要是因为他们意识到，通过 Azure 赚的钱比 Windows 更多。而 Azure 的用户想在上面跑 Linux，所以微软意识到，对 Linux 友好才最符合自身利益。

如今一些大公司正在 Linux 内核领域赚取巨额利润。在这样的背景下，严格坚守开源原则确实很难。比如曾经出现过分发 Linux 内核却不提供源代码的情况，这明显违反了 GPL，而执行起来非常困难。所以我理解那些悲观的朋友在担心什么，但我认为，现在所有人都相信开发工具应该是开源的、而且越来越多的开源项目正在发布——这本身就是一件非常美妙的事。

3. VS Code 是 Emacs 的精神继承者

Eric Wang: 作为 GNU 和 Emacs 的前维护者，您如何看待 Emacs 这类经典软件今天的角色？

Jim Blandy: 在现代的编程环境里，Emacs 在我心中依然有着特殊的位置。我第一次接触 Emacs 是在 1986 年，那是很久以前的事了。Emacs 迷人的地方在于，每次启动它，总会冒出一些出人意料、近乎魔法而又非常实用的功能。这话听着可能有点傻，但在当时，按一下 Tab 键就能得到正确的缩进，简直不可思议。

今天这看起来理所当然，但在那个年代，Emacs 能做到这一点是令人惊叹的。更了不起的是，当你打开一个 Perl 脚本，Emacs 已经“懂”Perl 了——知道该怎么缩进代码，甚至为 Perl 提供了完整的命令支持。这体现了 Emacs 社区的力量：无论你想拿它做什么，总有人已经先花力气把它变成了可能。Emacs 存在了这么多年，简化了太多事情，这也是它魅力的一部分。

那么，这股能量现在流向哪里了？显然，重心已经转移到了 Visual Studio Code（VS Code）。在 VS Code 里，你能找到各种稀奇古怪的插件，而这正是我当年喜欢 Emacs 的原因。所以我认为，VS Code 真正接过了 Emacs 的衣钵，成为了它的精神继承者。

我有个朋友给 VS Code 写了个插件：当你打字打得飞快时，屏幕上的文字会着火，还会响起吉他声。听起来很傻，但真的很有趣。他自己都忘了装过这个插件，有一次打字太快，文字突然着火并放起了吉他曲。那一刻把我带回了 Emacs 的年代。所以我觉得，这股能量找到了新的归宿，这是件好事。

但我也确实觉得 Emacs 现在有点过时了。当然，也许过时的是我自己。我还在用 Emacs，是因为它已经成了我的第二天性，是一种本能。好在 Emacs 一直在进步，比如用于 Git 的 Magit、org mode，还有相当不错的语言服务器支持，都还能让我惊喜。Emacs 在跟上时代。我会一直用它，用到最后一天。

4. 对用户的共情，是开源维护者最重要的能力

Eric Wang: 作为一位经验丰富的程序员和项目维护者，您认为成为一名优秀的程序员和维护者，最关键的技能或素质是什么？

Jim Blandy: 我其实并不觉得自己是个多么出色的程序员。我认为一个维护者最重要的事，是对用户抱有共情。我认识一些非常有才华的人，他们在解决问题时会把自己知道的每种工具都用上一遍，方案里塞满了各种宏和特性。

想一想，一个阅读能力没那么强的用户，要理解你写的东西是什么感受。对他们来说最容易理解的，是他们预期会看到的东西——不要用超出必要复杂度的语言。我想这是我作为维护者能给出的最重要的建议。

作为维护者，我的弱点大概在社交层面。举个例子，及时地做评审真的很重要，如果你不能及时评审别人对项目的贡献，那是很糟糕的。我评审得很慢，好在团队里有人非常擅长这件事。成功的项目往往有一支多元的团队，每个成员都有自己的兴趣和专长，并能把这些不同的技能和资源有效地整合起来，覆盖项目所需的方方面面。这或许才是真正的秘诀。

Eric Wang: 您此前提出过，开源实践是为程序员开发工具的最佳方式。您认为 OpenStreetMap 这样的研究，能被应用到音乐或地图制作之外的其他领域吗？

Jim Blandy: 我正在重新考虑要不要继续那项研究。OpenStreetMap 的存在让我觉得它可能已经没有必要了。OpenStreetMap 是一个杰出的项目，也是一个成功的开源案例。但在音乐领域，情况就不一样了。我认为人们对音乐的热爱，更多源自与创作者之间的情感连接。人们希望与创作者产生共鸣，感受他们的情绪。音乐更像是一种个人化的表达，而非集体协作。

在创作者身份至关重要的领域，比如音乐，开源模式可能并不适用。但在软件领域，人们更在意软件是否好用，而不是代码是谁写的。开源的本质是协作与集体的努力，很像维基百科。没有人会说“我是这篇维基百科条目的作者”，因为维基百科的条目没有单一作者——每个人都是作者。开源项目也是如此。你可以说“这个项目是我发起的”，但随着时间推移，代码不断演进，最终的成果已经不再属于某一个人。

作者 | 何苗
采访 | 王启隆 Eric Wang
出品 | GOSIM 开源创新汇