【編者按】全球 Ruby 社區是友善與支持的代名詞，人們用“Matz 人很好，所以我們也很友好”來形容它。多年來 Ruby 語言一直很流行，特別是那些需要處理大量繁重工作的初創公司。今年2 月份的時候，Ruby 舉行了 25 周年慶，而Ruby 已經發展成熟，Ruby 的流行部分來自 Ruby on Rails(RoR)Web 應用框架的成功，但RoR 不再是超級明星了，它面臨著激烈的競爭，大家懷疑它是否能夠再活 25 年。

以下為譯文：

軟件是如何誕生的?這也許不是大家希望在編程大會上聽到的主題演講者所提出的第一個問題，但這是來自日本的，Ruby 編程語言的創始人，和藹可親的松本行弘(Yukihiro Matsumoto，被稱為 Matz)，在為期兩天的年度 Bath Ruby 大會上，與 500 多位 Ruby 開發者交談時提出的第一個問題。

2 月份的時候，Ruby 舉行了 25 周年慶，盡管 Ruby 的第一個版本 0.95 是于 1995 年 12 月正式發布的。針對自己的哲學問題，Matz 建議說軟件在命名時誕生。在 Ruby 誕生兩年前的 1993 年 2 月 24 日，東京和社交媒體舉行了盛大的慶祝活動。 Matz 說他想用一個寶石命名，他很風趣地說：“Ruby 很短，Ruby 很漂亮而且昂貴，所以我給自己的語言起名叫做 Ruby。”

然而，Matz 近五年來第一次來到英國，并不僅僅是為了吃個生日蛋糕。Ruby 可能已經發展成熟了，但是大家仍然懷疑它是否能夠再活 25 年。就像它的創造者一樣，Ruby 語言非常討人喜歡，擁有忠實的追隨者。比如，它的語法可讀性非常高，但是表達方式非常簡潔，且是一種動態的、反射式的、面向對象的通用編程語言，它直觀且易于學習。Ruby 不想限制使用者，或者引用 Matz 經常說的一句話：“Ruby 旨在讓程序員開心。”

但并非每個人都很開心。由于 Ruby on Rails(RoR)Web 應用程序框架的成功，多年來 Ruby 語言一直很流行，特別是那些需要處理大量繁重工作的初創公司。這一顯著的優勢使得 Ruby 在 2012 年的 RedMonk 語言排行榜上飆升至第五位，該排行榜結合了 GitHub 和 Stack Overflow 上語言的排名來評估語言的流行度，后來 Ruby 的排名下降到了第八位。

RoR 雖然很受歡迎，但并不是它的巨星，它面臨著激烈的競爭，因為規模伸縮等問題已成為互聯網公司更為關注的問題。例如，Java 的框架 Node.js 變得很流行，因為它的回調函數可以用更少的內存來處理大量的連接。

自2012年以來，在RedMonk排名中，Ruby在排名前十的編程語言中緩慢下滑。且一直在第十名上下擺動，這反映了Ruby已經發展成熟以及Ruby on Rails Web應用程序框架優勢的減弱。

很明顯，Matz 知道任何編程語言的使用都是由語言社區以及生態系統(RoR 是一個令人驚訝的例子)發展而來的項目和框架推動的，而通常不是語言本身。Ruby 也不例外，即使 Ruby 贏得了很多用戶的喜愛。因此，在 Bath Ruby 大會上，盡管對于在自己的語言中犯下的錯誤他表達了遺憾，同時他也想明確前進的方向，解決那些造成開發人員放棄 Ruby 的性能和規模問題。

Matz 解決關鍵問題的方法也表達了他看到的兩個關鍵趨勢：可擴展性，以及他所稱的更聰明的伙伴。

為了解決可擴展性并創造更高的生產力，Matz 認為：“更快的執行速度，更少的代碼，更小的團隊是提高生產力的關鍵。”

盡管計算機的運行速度越來越快，但這還不夠，Matz 說：“我們需要更快的執行速度，因為我們需要處理更多的數據和更多的訪問。我們很接近內核性能的極限了。這就是為什么 Ruby 3.0 的目標是比 Ruby 2.0 快三倍”，Matz 稱之為“Ruby3x3”。“說起來簡單，”Matz 承認 Ruby 1.8“太慢”，這是一個錯誤。

笹田耕一在 YARV(Ruby 的另外一個虛擬機)上的工作改進了 Ruby 1.9 的性能，Matz 說：“從那時起，我們一直在努力提高虛擬機的性能，但這還不夠。”

JIT 時代

為了進一步提高性能，Ruby 進一步引入了 JIT(即時編譯)技術，該技術已為 JVM 和其他語言使用。Matz 確認說：“我們已經創建了這個 JIT 編譯器的原型，Ruby 2.6 可能會在圣誕節那天發布。”

2.6 預覽版本 1 中可以看到 MJIT 的初步實現。目前已經可以利用–jit 選項檢查并將 Ruby 程序編譯成本地代碼，但 Matz 說該選項還“未經優化”，不過至少“對于 CPU 密集型任務來說它的運行速度比 Ruby 2.0 加快兩倍”，他認為這“十分有希望，且 JIT 編譯器的性能提高還有很大的空間。”特別是對于 CPU 密集型的任務，Matz 相信他們能夠將性能提高三倍。

根據 John Hawthorn 在 MJIT 代碼中評論，目前的 JIT 編譯器原型使用了一個非同尋常的方法：利用 C 編譯器、GCC 和 LLVM Clang 來實現，盡管 Ruby 代碼是單線程的，但 MJIT 是在第二個線程內編譯的。

Shannon Skipper 提供了關于 MJIT 工作原理的最清晰的概括：

• “通過 MJIT，某些 Ruby YARV 指令被轉換為 C 代碼并放入一個.c 文件，該文件由 GCC 或 Clang 編譯為.so 動態庫文件。然后在下一次 RubyVM 看到相同的 YARV 指令時，可以使用這個緩存的根據動態庫預編譯好的本地代碼。”

Matz 還認為，可擴展性應該意味著創造更少的代碼，他風趣地說，因為“更多的代碼意味著更多的維護、更多的調試、更多的時間、更低的生產力，以及更多的噩夢。”

然而，更少的 Ruby 代碼并不意味著語言的語法將會發生重大變化。很大程度上是因為 Ruby 幾乎沒有改變的余地，Matz 說：“我們使用了所有字符。所有字符都被用到了。”

作為自由發展的代表者，他也不打算為了自尊心而改變語法，并看到現有的 Ruby 程序遭到破壞，所以他很謹慎地說：“我們不會對 Ruby 語法做出太多改動。”

根據 Matz 的說法，處理可擴展性并提高生產力的工作應該由小團隊來擔任。引用亞馬遜 CEO Jeff Bezos 的“兩個披薩原則”：“如果團隊人數眾多，兩個比薩都不夠吃，那么說明你的團隊太大了。”坦白說，這可能要看團隊里都有誰，以及他們愛不愛吃披薩(開個玩笑)。但是 Matz 說這個原則是經驗之談，“團隊越大，所需要的溝通就越多，而溝通本身就是成本。”

更多抽象

近年來，人們一直在激烈的爭論，關于需要更多的 Ruby 抽象來為開發人員提供服務，以便他們構建適合不同領域的應用程序，所以很高興聽到 Matz 說 Ruby 需要“更多抽象”，并提到 Ruby on Rails 以模型-視圖-控制器(MVC)抽象為例。Ruby 的創始人并不認為它們是完美的，“但它們提供了對未來生產力至關重要的抽象。”

Matz 詳細闡述的一個關鍵抽象是關于一個名叫 Guild 的并發抽象項目。

Matz 承認：“我對 Ruby 的設計感到遺憾的一件事是線程……它太簡陋了。”但是 Ruby 的成功也有壞處：太多人使用該語言，所以 Matz 認為已經來不及刪除線程了。

他說，“我認為可以包含一個新的抽象概念，并且阻止更多人使用線程。”Matz 還告訴 Bath 的與會者：“Guild 是 Ruby 的一次實驗，可以提供更好的方法，Guild 完全是獨立的。”

“基本上 Guilds 之間沒有共享的狀態。這意味著我們不必擔心狀態分享，所以我們不必關心鎖或互斥。Guild 之間通過通道或隊列進行溝通。”

Matz 預計將在 Ruby 2.7 或 2.8 中發布 Guild 的并發抽象。

Ruby 的另一個代碼項目是 Steep。這是對 Ruby 的靜態類型分析的嘗試，Matz 解釋說：“分析 Ruby 的類型信息很困難，因為 Ruby 是一種動態語言，所以你可以隨意使用所有類型。”Ruby 的某些子集可以是靜態類的，所以 Matz 說他們可以添加這些靜態類型的檢查，這“有點像 Type 的用戶定義的類型信息。我們將盡可能推斷類型，并從外部類型定義文件或運行時的配置文件類型分析中獲取信息……”

Matz 表示，通過這種分析，開發人員可以在編譯時檢測到更多的錯誤，“我們無法實現 100%的安全檢測，Ruby 不可能做到，但是我們可以檢測到 20-40%的錯誤，”Matz 說與完全不檢測相比這是個巨大的進步。

松本還談到了 Ruby 要成為“聰明的伙伴”以及程序員最好的朋友。“現在我們已經開始使用智能計算機了，比如 RuboCop [靜態代碼分析器]就是一種可以幫助你的方式，”不過，Matz 對許多放聲大笑的觀眾說，他也“不是很喜歡 RuboCop 的默認規則。”Matz 建議，將來在編譯成功程序的時候，“Ruby 可以建議‘你給這個方法傳遞了個字符串，但是其實它期待一個整數。’”在主題演講結束后，Matz 詳細闡述了他對編程互動的期望，他同意這些聽起來很像 Tony Stark 的 Jarvis。Matz 說他很想看看“人工智能與我互動，幫助我建立更好的軟件。”

注意版本變更的幅度

版本變更可能使得軟件無法按照預期工作。過去的錯誤讓 Matz 很擔心，他說：“過去我們的版本變更很大，例如在 1.8 和 1.9 之間的變更很大，并且引入很多破壞性的變更，所以在五年中我們的社區分裂成了兩個。”

盡管以往發生過這樣的事情，比如 Python 2 和 Python 3 就是典型的例子，Matz 認為這是一個悲劇：“我們不會再犯這種錯誤，所以我們會不斷改進。我們會在 2.6 中加入 JIT 編譯器，而不是等到 Ruby 3.0。將來我們會在 Ruby 2.7-2.8 中加入一些并發抽象類型，但是不會出現有破壞性的變更……我們將保證每個 Ruby 2 的程序都可以在 Ruby 3 中運行。”

一改 Ruby 目前逐步衰落的情況不是一件易事，Matz 似乎也明白這一點。在發表主題演講的早上，當看到最近 Stack Overflow 的開發者調查結果時，他的微笑一下消失了，“Go 和 Rust 是最受歡迎的語言，不幸的是 Ruby 不在其中。我相信 Ruby 會在將來重振雄風。人們喜歡新技術。十年前在 Rails 的帶動下 Ruby 炙手可熱。現在 Ruby 雖然不算熱門，但它很穩定。”

然而，Ruby 已經跨越了鴻溝進入了成熟階段，Matz 不會放棄：“Ruby 是一種很好的語言，可以幫助你提高工作效率，我希望 Ruby 可以永遠如此。這意味著我們不斷改進，所以我們不能停下來。”

在日本外舉行首屆 Ruby Hack Challenge 大會正是我們前進的一步，此次會議上周在 Cookpad(一家以分享菜譜為主的網站，廣泛使用了 Ruby 開發的平臺)新的國際總部 Bristol 舉行。這些挑戰是讓有抱負的代碼提交者學習如何擴展 Ruby 的功能、修改 bug 和提高 Ruby 性能的機會。

Cookpad 的 CTO，Bath Ruby 大會的主辦方 Miles Bathroffe 說，此次會議主要是為了 Ruby 解釋器，該解釋器說明了計算機是如何運行 Ruby 編寫的程序的。

此次會議的目標之一是允許參與者直接為下一版本的 Ruby 解釋器貢獻代碼。

隨著 Ruby 3 的發布日益臨近，非官方計劃是在 2020 年，很明顯 Matz 希望繼續提供一種工具，幫助程序員專注于編程有趣和令人愉快的方面。

與松本行弘(Matz)談話的時候，我注意到兩件事情。首先，他會盡一切努力讓 Ruby 存活下來并發展;其次，他非常享受自己在做的事情。他對 Ruby 及其社區充滿熱情，而他的外表看起來很簡樸：編程是一件有趣的事情，在過去的 25 年中他玩的很開心，現在他已經 52 歲了，他希望在未來的 25 年中，可以繼續快樂地為這門語言工作，這個他夢寐以求并在 17 歲時在一個筆記本上寫下的語言。