Ruby 之父：不要违背开发人员的本能

Grigory：Ruby 3.0 是一个大的发布版本，其中包含了许多实验、反馈、挑战和特性。您最喜欢 Ruby 3.0 的哪个特性？

松本行弘：我喜欢模式匹配，包括右侧赋值。同时，我对 Ractor 和静态类型检查也很感兴趣，因为我认为它将改变并增强 Ruby 编程的文化。

Grigory：是的，静态类型检查真的很棒。我很期待看到您是如何在标准库和框架中实现添加类型的这个想法的。模式匹配也确实很棒。我很怀念 Python 中的这个特性，很高兴能在 Ruby 中使用它。Ruby 3.0 是向后兼容的。这很好，因为开发人员不喜欢破坏，他们喜欢不破坏向后兼容性的想法。你会把这种方法推荐给其他语言吗？保持向后兼容性是个好主意吗？

松本行弘：是的。当我开始 Ruby 编程时，Ruby 社区还很小。因此，可以抛弃旧版本并打破当时的 Ruby 语言语法。但随着时间的推移，Ruby 社区变得越来越大，世界各地有数百万的 Ruby 程序员，现在即使是最微小的改变也能造成破坏。

我们上次在 Ruby 1.9 中做了一个大的破坏，我们吸取了教训，即大的破坏可以长期分裂社区。在 Ruby 1.9 后，我做了一个决定，即使是在主版本上，我们也不会做大的破坏。其他语言，如 Python 3 或 PHP 6，也有类似的问题，这让我们认识到向后兼容的重要性。

语言设计师希望不断进步，做出改变，改进语言。但如果要以兼容性为代价，那就不好了。我们应尽量保持兼容性。

然而，另一方面，就像你说的，开发人员喜欢新的东西，所以我们必须添加新的特性，这有点矛盾。但我想我们已经尽力了，至少对于 Ruby 3.0 来说是这样。

Grigory：是的。做得很好。我希望其他语言也能跟上你的步伐，保持向后兼容性。

我记得，10 或 15 年前，所有这些悲剧都发生在 Python 从版本 2 过渡到版本 3 的过程中。这种情况持续了几年，核心开发人员甚至不确定他们是否应该继续开发 Python 3，或者干脆退回到版本 2 会更好。同样，PHP 也发生过类似的事情。我很高兴，目前，我们正处于开发阶段，我们可以在不让数以百万计的开发人员感到难过的情况下提供令人惊叹的特性。

我们来谈谈特性吧。编程语言都是彼此借鉴的。我们可以在 Ruby 中看到模式匹配，其他开发人员也可以在 Python、JavaScript 和现在的 Ruby 中使用 hash destructuring。也许右侧赋值将来也会被 Python 或 JavaScript 借鉴。您对下一个版本有什么计划嘛？您有什么疯狂的想法，您想借鉴什么，或者只是尝试些什么？

松本行弘：这是个很好的问题！但是我们关注 Ruby 3 已经有很长一段时间了，而且它才发布了一个月，所以我对未来还没有那些疯狂的想法。它可能是增强 Ruby 的 Ractor 和模块（Module）系统。Java 和 Python 都有模块系统。另外，提供一个结构化的打包（Packaging）系统可能也很有用。我有一些模糊的想法，但还不够具体，所以无法透露太多。也许你得等一年左右的时间才行。

Grigory：没问题。我写代码已经有 20 年了，我也很乐意再写 20 年。顺便问一句，Ruby 的打包系统可能不像 Java 那么全面，但是 Ruby 允许用户安装和使用同一依赖项的多个版本。这实际上很好，举例来说，因为 Python 只能使用一个版本的依赖，这会带来很多问题。此外 JavaScript、Node.js 也只是将版本放在特定的目录中。因此，Ruby 当前系统给人的感觉非常好，但是我们会一直期待新的改进。

松本行弘：是的，我们可能会准备一些容器，以便不同版本的 Gem 可以存放在不同的容器中。

Grigory：是的，您有足够的时间来对其进行测试。现在，出现了很多新的编程语言。您是如何看待它们的？您是否有一些 RSS 订阅或者有开发人员来找您，向您介绍一些新特性？

松本行弘：我的主要信息渠道是 Ruby Redmine。我们有收到来自社区的大量建议，这些建议激励我设计新特性。我不得不拒绝其中的大多数，但是这些改进语言的想法启发我去设计新的想法。

在疫情之前，我参加了许多会议，并与人们讨论了 Ruby 和编程问题，这样我就能看到语言和环境的障碍、烦恼或弊端，然后我尝试改进它们。这些讨论给了我很大的启发。但在过去的一年半里，我再也无法进行这样对话了，这是疫情的一大弊端。

此外，我还上网冲浪，阅读有关编程语言和 Ruby 的博客。这些文章也给了我启发。

Grigory：所以，如果我们的读者中有谁想给 Yukihiro 提供一些有趣的想法，都可以用 Ruby Redmine 来提建议！关于疫情这个问题，一切事情都要在家中完成，所有会议都是线上进行的，从您的角度来看，这对 Ruby 的开发、采用和社区有什么影响？

松本行弘：日常的开发并没有太大的改变。我住在离东京很远的地方，即使是疫情之前，我们开发人员的会议和沟通都是在线上进行的，所以这个过程并没有变化。但正如我之前所说的，我们现在没有实体会议了，所以这是一件坏事。

但是，另一方面，我不必经常出差了。我可以呆在家里，有更多的时间呆在我的电脑前，花更多的时间在编程或 Ruby 身上。

Grigory：那太好了。顺便说一下，在去年疫情期间，我们组织并参加了很多线上会议，您也是这样。那您对线上会议有什么看法呢？它们有用吗？您能通过它们收集反馈并与其他 Ruby 开发人员交流吗？

松本行弘：对于与会者来说，线上会议的价值仍然存在，但是以演示的形式存在的。但没关系，与此同时，线下交流，一起吃晚饭或是傻乎乎的聊天，这些侧面渠道都从线上会议中消失了，这是我非常怀念的事情。会议的价值在于这种交流。

Grigory：您用 Ruby 语言做了大量实验。您可以添加特性来增强新版本，如果您和开发人员不喜欢，则可以删除它们。我在其他语言中从未见过这样的事情。这对 Ruby 来说有什么独特之处吗？您在其他语言中看到过类似的东西吗，还是您是唯一一个这样做的人？这种方法的优缺点是什么，您给成千上万的开发人员提供了一些可以尝试的东西，但是如果不成功，您就会收回吗？

松本行弘：当 Ruby 社区还很小的时候，他们并不关心更改，一切都是实验性的。如果无法解决问题，我们就会删了它，没有人关心兼容性。但是那些美好的时光已经一去不复返了，现在我们有了一个庞大的社区。

因此，这类更改的成本每年都在增加。这意味着 Ruby 的设计决策无法逆转。这意味着设计师不能犯错。我只是个普通人，我承认我犯了很多错误。

同时，虽然 Ruby 社区很庞大，但我们的 Ruby 核心开发人员团队还不足以预测未来。

如果我能提出一些建议，或者我们能在核心社区内尝试这些想法，那是没问题的。但我们的核心社区还不够大，无法在发布之前对这些想法进行试验。我们对 Ruby 特性所做的实验是一种折衷，适合当前核心开发人员社区的规模。大型 Ruby 社区不允许我犯错，但是核心开发人员社区的规模不允许我们在内部进行所有实验。我们必须让社区去尝试一些东西。

一旦我们的核心社区足够大，可以进行内部实验，我们就不再需要公共实验过程了。但是现在，这是一种妥协。

其他语言也会这样。Python 和 PHP 社区的规模足够大，可以在核心开发人员内部进行各种实验。但是目前的 Ruby 社区规模不允许这样的过程。

Grigory：我看到 Ruby 社区和语言采用正在增长。因此，我希望在未来的几年中，它将有一个坚实的机会，将实验限制在核心开发人员内部，而世界各地的所有 Ruby 开发人员收到的是一个他们可以使用的最终版本。

松本行弘：语言设计很有趣。语言实验的一个非常大的好处是邀请用户社区来帮助设计语言。即使我们有一个足够大的核心开发人员社区，我们也可以邀请广大的 Ruby 社区来参与一些语言实验。

Grigory：是的，或者是那些想要参与语言开发的用户。他们可以加入核心社区，证明自己有资格参与所有这些实验。

松本行弘：大多数 Ruby 用户甚至都没有考虑加入到设计过程的可能性！那会很有用。

Grigory：我有一个关于所有 Ractor 和异步 I/O 纤程（Fibers）的棘手问题。我是并行和多任务并发的忠实拥护者。而现在在 Ruby 3 中，开发人员有了很大的选择余地。对于并行性，我们可以使用进程（Processes）或 Ractor，对于多任务，我们可以使用线程（Threads）或异步纤程（Fibers）。一个典型的 Ruby 开发人员如何在它们之间做选择呢？

松本行弘：对于 Web 应用程序，Web 开发人员无需关心并发性，因为像 Unicon、Puma 和 Falcon 这样的应用服务器会处理并发性。Unicorn 使用进程，Puma 使用线程，Falcon 使用 Fibers。应用服务器的选择直接影响并发系统的选择。也许将来我们会有一个基于 Ractor 的应用服务器。但目前还没有，因此应用服务器的选择会直接影响并发模型的选择。因此，Web 开发人员不必关心并发性。

典型的开发人员在研究应用程序瓶颈时会进行并发性试验。如果输入 / 输出是瓶颈，那么明智的做法是选择异步 Fibers。异步 Fibers 针对 I/O 多路复用进行了优化。如果你的程序使用了大量的 I/O 通信，则选择异步纤程。如果你想试验多核及 CPU 密集型任务，那么选择 Ractor。

这是基本的选择，因为当前 Ractor 实现是将一个 Ractor 与一个原生 OS 线程相匹配。现在还无法创建数百万个 Ractor，因为每个 Ractor 都会消耗几兆字节的堆内存。这是巨大的。而 Fibers 只消耗几千字节或更少的内存。因此，你不必担心 Fibers 的内存成本，你可以创建任意数量的 Fibers。这是选择的第二个标准。负责 Ractor 的 Koichi 正在努力改进这些。也许，在未来，Ractor 也不会再消耗那么多内存了。

也许将来，我们能够像在 Go 中使用 Goroutines 一样使用 Ractors。但这是一个未来的故事。

Grigory：是的，听起来前途一片光明。到目前为止，我真的很喜欢框架（Framework）作者的想法，将一些著名的 Ruby 约定置于配置之上，这样 Ruby 开发人员可以使用框架作者预先选定的模型。然后，如果运行缓慢，Ruby 开发人员可以更深入地研究并将 Rails 切换到其他的并发原语上。能有选择的余地真是太好了。

还有一个关于速度的问题。

最近，我偶然发现了一篇由 David Heinemeier Hanson 撰写的短文，他提到了一个有趣的发现：在他提供 Basecamp 和 Hey.com 电子邮件服务的所有服务器中，只有 15% 的 Basecamp 运维预算花在 Ruby 上。即使把 Ruby 的速度提高 10 倍也改变不了游戏规则。Ruby 的原始速度重要吗？

松本行弘：我有点百感交集。对于大多数 Web 应用程序而言，Ruby 和业务逻辑并不是瓶颈。大部分时间都是花在数据库、网络连接以及处理操作系统上。Shopify 和 GitHub 使用 Ruby，所以速度并没有那么重要。它们已经成长壮大了，是没有任何问题的。如果我们关注程序员的生产力，那么性能并不是最大的问题。

很长一段时间，我都是这么认为的，直到几年前，我意识到很多人都是基于微基准测试来做决定的。

所有这些斐波纳契（Fibonacci）数和 n-body 基准测试都有点愚，但这是开发人员的本能。几年前，我放弃了让开发人员违背本能的做法，开始改进 Ruby 的性能，甚至在微基准测试上也是如此。

JIT 编译器就是其中之一。JIT 编译器目前并没有提高 Rails 应用程序的性能，因为应用程序将时间花在数据库和网络连接上了。但是 JIT 编译器可以提高微基准测试的性能。

但是目前，由于存在瓶颈，编译器并没有对 Rails 应用程序的性能提高多少。应用程序是在数据库访问或网络实践中设置的，但编译器可以提高微基准测试的性能。我们在各个方面都正在改进 Ruby 的性能，包括微基准测试。

几年前，我就开始关注微基准测试的性能了。这有点傻，但这是 Web 开发人员的本能。

Grigory：是的，JIT 确实有帮助。上次我检查人工微基准测试时，仅仅启用了 Ruby 的 JIT，速度就快了十倍。所以这真的很有帮助。

松本行弘：是的，我们不能与本能抗争。

Grigory：最后一个技术问题是关于标准库是否是即装即用的。有两种方法。第一种是 Python 闻名之处。包含一个巨大的标准库，其中包括所有内容，如 FTP 客户端、电子邮件客户端和 zip 存档。初学者都喜欢它，因为他们可以使用教程，不必安装依赖项就可以获得一切。且一切都正常。核心开发人员就不太喜欢它了，因为他们需要支持这个庞大的标准库。他们无法做出重大的更改，因为这会让所有学习该语言的开发人员都感到沮丧。而这些库，它们的老化速度又相当快。另一种方法是 Ruby 的基础、低级的标准库和生态系统，它们蓬勃发展并为所有的东西提供了有竞争力的解决方案。这对开发人员的竞争是非常有利的，并且能够推动创新。但是新开发人员会很惊讶，他们不知道该用什么。因此，这有争议。您是如何看待这一争议的呢？

松本行弘：是的，Ruby 1.8 采用了“胖标准库”的方法，但是随着时间的推移，有些库没有得到维护。我们改变了方法，把库分成了多个 Gem。

很少有人在 Ruby 1.9 时使用 RubyGems，但是在 Ruby 2.0 的时候，RubyGems 被设置成更具通用性的了。有了 Ruby 2.0，RubyGems 社区变得越来越大，每个人都在使用 RubyGems。所以，如果每个人都使用 Gem，我们就不需要打包所有东西。因此，我们逐渐将标准库划分成不同的 Gem，使标准发行版本更精简且易于维护。

请记住，我们的核心开发人员社区还不够大，不足以成为所有领域的专家。一般来说，我们的语言核心开发人员不是 Web 开发人员。我们不擅长维护基于 Web 的技术，比如 Webrick、HTTP 客户端，甚至处理 XML。

最好的办法将这些难以维护的零件远离标准发行版本，并使其成为 Gem。现在，开发人员可以创建具有竞争力、更好维护的 Gem。自然竞争是一件好事！

Grigory：那么，对于那些 Ruby 的初学者，或者那些具有丰富经验但只想温习一下 Ruby 3 知识的开发人员，您有什么建议呢？在 2021 年，您会推荐哪些书、博客或学习平台？

松本行弘：在 2021 年，railstutorial.org 以及 guides.rubyonrails.org 为初学者提供了最佳的学习资料。Web 应用程序是编程的一个很好的示例，它接近于真实的产品。现在，运行脚手架并编写几行 Ruby 代码就可以创建一个简单的 Web 应用程序。您可以在几秒内增强这些 Web 应用程序，并查看更新后改进了的 Web 应用程序。

较短的开发周期鼓励开发人员学习更多的知识。在开发人员学习了 Rails 或 Ruby 的内部架构之后，他们可以学习任何他们想要的东西：机器学习、嵌入式系统。对于初学者来说，Web 应用程序本身就是一个很好的起点。

Grigory：最后一个问题。最近我在日本看到了很多 Ruby 奖项，还有政府官员感谢开发者的照片等等。在其他国家或其他语言中，我从未见过这样的情况。

那么，政府和所有官方所举办的活动对 Ruby 的这种赞赏是日本或日本文化所特有的吗？或者这是 Ruby 所特有的，还是两者都有？

松本行弘：无论是在日本还是日本以外的地方，比如俄罗斯、美国和欧洲，开发者社区都是非常相似的。但不同的是，Ruby 被认为是在日本本土的，一些日本人希望鼓励它，特别是当地政府部门。

我个人和一些城市的州长、市长的关系都很好。他们希望通过组织会议和颁奖来鼓励 Ruby 社区。这是他们鼓励一种被认为是在日本诞生的技术社区的方式。从这个意义上说，这些地方政府项目是日本所特有的，但当地的开发人员社区与其他国家的是非常相似的。

视频采访连接：

https://youtu.be/B-UFFo4M-04?fileGuid=jKdG9qXdRQ6q9t69

结论

通过对松本行弘先生的采访，我们了解了更多关于 Ruby 的最新特性以及社区的发展是如何影响语言发展的。我们也对 Ruby 的未来有了一些深刻的了解。

原文链接：

https://evrone.com/yukihiro-matsumoto-interview-2021?fileGuid=jKdG9qXdRQ6q9t69