RubyKaigi 2024 キーノートレポート

まつもとゆきひろさん「Better Ruby」 ~RubyKaigi 2024 3日目キーノート

2024年5月15日から17日まで、沖縄県那覇市の那覇文化芸術劇場なはーとでRubyKaigi 2024が開催されました。3日目の基調講演はRubyの作者である、まつもとゆきひろさんが登壇し、⁠Better Ruby」というタイトルで講演を行いました。

まつもとさんは、Rubyの良さ、Rubyをより良くするための4つの側面、Rubyの未来像について話しました。

まつもとさんによるキーノート

Rubyの良さ

「Rubyは本当に素晴らしい言語で、これを日本語で自画自賛と言います」とまつもとさんは話し始め、Rubyの良さについて順に紹介しました。

楽しい

まず最初にRubyの良いところとして、コードを書いていて楽しいという点を取り上げました。Rubyの公式サイトにある「A PROGRAMMER'S BEST FRIEND」というスローガンは、⁠プログラマーがコードを書くときにRubyが友であってほしい」という願いから掲げたそうです。

Rubyには、あったら良いなと思う機能がだいたい揃っていて、かゆいところに手が届く便利さがあります。加えて、Rubyが生まれた30年前から、それらの機能がクラスを軸として分類されていることも非常に良い点だと述べました。

また、制限が少なく作られていることもRubyの良い点で、理不尽な制限に悩まずにコードを書くことができます。例として、Integerがサイズによって制限されることなく正しく表現できることや、言語が定義した機能とユーザーが定義した機能を区別することなく同じように利用できることを挙げました。

Rubyの良い点は各種ツールやコミュニティにもあると言います。Rubyでの開発を支援する各種ツールが提供されていることで、高い生産性が実現されています。それらのほとんどはコミュニティから生まれており、コミュニティがRubyでコードを書く楽しさを支援してくれていると述べました。

生産性が高い

続いて、生産性が高いこともRubyの大きな特徴であるとし、主な要因として、前述した理不尽な制限が少ないことと、Ruby on Railsの存在の2つを挙げています。

Ruby on Railsはリリースから20年経過した現在でも最先端のフレームワークとしてたくさんの企業や個人に使用されています。今回のRubyKaigiでも、Ruby on Railsを使う多くの企業がスポンサーとして参加しており、多くのRubyエンジニアの求人も掲示されていました。

そういったことから「RubyやRuby on Railsが社会の一部を動かしていると言っても過言ではない」とまつもとさんは述べています。

効率が良い

効率という点では過去のRubyが遅かったことは事実で、いまだにRubyは遅いと言われていることがありますが、現在のRubyは以前に比べて高速化されていると強調しました。

多くの大企業で利用するのに十分な速度で実行できるようになっており、例えばGitHubやShopify、SquareなどもRubyで動いています。なかでもGitHubは他言語でのソフトウェア開発にも利用されており、そのことからもRubyは非常に大事であるとまつもとさんは言います。

以上の観点から「Rubyは単にGoodを超えてGreatであるといっても言い過ぎではない」と述べました。

Rubyをより良くするための4つの側面

前述のとおり、まつもとさんは「RubyはGreatである」としながらも、⁠我々は欲張りなので」と4つの側面からRubyの改善点を挙げました。

1. VMのパフォーマンス

「プログラマーはみんな速い言語が好き」ということで、まずはRubyのパフォーマンス改善に関する歴史のおさらいから始まりました。

2007年にRubyの新しいバーチャルマシン(以下VMと表記)としてYARVがリリースされ、それ以前のTree-Walking型と呼ばれるインタプリタと比べて、ベンチマーク結果として5〜50倍程度高速に動くようになりました。

その後さらなるパフォーマンス改善を求めて2018年にMJITが導入されました。これはアメリカで開催されたRubyConf 2014のキーノートでまつもとさんが発表したRuby 3x3(Ruby3はRuby2の3倍速くする)というスローガンの実践のひとつとして開発されたものです。しかし、指標のひとつとしていたOptcarrotによるベンチマーク結果は宣言どおりのパフォーマンスを実現したものの、Railsアプリケーションにおいての効果は限定的で一般的なRubyユーザーにとって不十分な結果になってしまったと言います。

そこで、より実効性のあるパフォーマンス改善を目指し2022年にYJITが導入されました。Lazy Basic Block Versioningというアルゴリズムを採用した、より高速なJITコンパイラです。現時点ではRustで実装されています。これにより、Railsアプリケーションにおいて1.8倍の高速化が実現しました。YJITは更なる高速化が検討されており、今後一層のパフォーマンス改善が期待できるとのことでした。

さらに、Rubyのコアチームにとって頭の痛い課題であった古いRubyが使われ続ける問題も、YJITの導入によって改善しつつあると言います。⁠YJITが使える新しいバージョンを利用すれば、Railsアプリケーションのパフォーマンスが5%〜10%改善する」という評価が広まり「それならバージョンを上げよう」というモチベーションに繋がったというエピソードが披露され、⁠パフォーマンスは大体の問題を解決する」とまとめました。

「RubyのVMを今後も高速化し続けることによって、Rubyはより偉大になっていくと考えています」という言葉で最初のトピックを締めくくりました。

2. メモリのパフォーマンス

続く2つ目のトピックもパフォーマンス改善に関する話題となりましたが、今度はメモリ消費の側面からです。

VMには唯一と呼べるボトルネックが存在しないため、複数のアプローチでパフォーマンス改善を行う必要があり、その一つにメモリ関係の問題があるとのことでした。

Rubyにおいてはこれまで、オブジェクトのヒープの圧縮やメモリ割り当てのサイズを可変長にすることでメモリの消費効率を上げる、Object Shapeを用いてインスタンス変数へのアクセスを効率化する、その他GCの様々な改善を行うことによってメモリのパフォーマンス改善を行ってきたと言います。

現代のWebアプリケーションではメモリがボトルネックになりやすく、アプリケーション実行のためにより多くのメモリを必要としています。Rubyがより省メモリで動くようになれば、今までメモリに割いていたお金を開発効率の向上などのより有意義な活動へ充てられる、とまつもとさんは述べました。

Rubyをより省メモリにすることによって、Rubyをより偉大にできる、と結論付けました。

3. 並列実行によるパフォーマンス

「3番目の要素はですね……大体想像ついてますよね?」という前置きで会場のひと笑いを誘ったあと、3つ目のトピックとしてまつもとさんは並列実行によるパフォーマンスの話を始めました。

Rubyが誕生した1994年当時の時代背景もあり、当初はマルチコアのCPUを想定した作りになっていませんでした。Rubyにはかなり早い時期からThreadが導入されていたものの、これは処理パフォーマンス向上を意図しておらず、マルチスレッドの実装をシンプルに書くことを主な目的としていました。その流れを汲んだ関係で、現代のRubyにおいても大量のThreadがパフォーマンスの向上に寄与することはないと言います。

一方、現代のプログラミングにおいて、⁠Thread」「Concurrency」といった名前の付く仕組みはパフォーマンス改善を期待して利用されることが増えてきているのに対し、今のRubyにおけるThreadの実装や性能特性はあまりユーザーの期待に応えたものになっていないという現実があります。

現在のRubyでコンカレンシーを担保する方法として、Unix系OSのプロセス・Fiber・Ractorと様々なアプローチを紹介しつつ、それぞれが抱える難しさについても述べました。

  • Thread:GVLがあるためマルチコアでは使いづらい
  • (Unix系OSの)プロセス:コンカレンシーを担保したいときに向くが、生成コストが重く、プロセス間の通信にもコストがかかる
  • Fiber:I/Oのためのデータのコンカレンシーを確保したい場合に向くが、マルチコアが使えない
  • Ractor:(まつもとさんの見解として)正直なところ、まだプロダクション利用を広く勧められる段階ではない

また、今後の展望として、以下のものを紹介しました。

  • M:Nスレッド、Rubyスレッドの数とネイティブスレッドの数を独立させる
  • より軽量なRactorを目指す
  • RactorローカルのGCを導入する
  • Fiber Schedulerを導入する

Rubyがコンカレンシーを活用することによってパフォーマンスが向上し、並列実行を前提としていてもシンプルにコードを記述できるようになることでRubyがより偉大になっていく、という言葉でトピックを締めくくりました。

4. 開発者のパフォーマンス

最後のトピックは開発者のパフォーマンスについてです。

ソフトウェアの実行効率はとても重要な一方、開発者のパフォーマンスに目を向けることも非常に重要と考えている、とまつもとさんは述べました。

かつて、プレーンなテキストエディタでプログラミングを行っていた時代に比べ、現代においてはシンタックスハイライトなどの各種ツールによるサポートを受けることが当たり前になっています。

そのような各種ツールが目的を達成するためには、ツール自身がRubyのコードを解釈する必要があり、そのための大事な役割を担うのがパーサーです。現在、Ruby本体が使っているパーサー、ツールが使っているパーサーそれぞれが独立して開発されているため、大変な苦労があるそうです。そこで、⁠Universal Parser」としてRuby本体と各種ツールで一つのパーサーを共通して使うようにすることを考えたと言います。

その候補として、手書きでパーサーを実装しているため処理効率の良いPrismと、形式的な定義からパーサーを生成するため正しさの観点で魅力的であるLramaを挙げました。

現時点では、Universal Parserの外部に対してのインターフェースは基本的にPrismのものをベースに採用することとし、一方でRuby本体のUniversal ParserのコアとしてPrismを採用するかどうかはまだ保留にしたいとのことでした。

まつもとさんは、この2つのパーサーに健全な競争をしてほしいという意向を示しました。

さらに、原則としてRubyへの文法変更を行わない「シンタックスモラトリアム期間」を設ける構想について話しました。この期間には、文法変更に伴い発生する大きな開発コストを回避することで、クオリティの向上やカバレッジを上げる作業に充ててほしいという意図があると言います。これはPrismとLramaに平等に機会を設ける狙いがあるものの、発表時点においてPrismの開発者との会話をまだ行っていない段階で、不要と判断されれば撤回する可能性もあると述べました。

具体的な期間としては未定としつつ、2024年いっぱいから2〜3年程度の幅で、概ね1年程度を目途として考えていると説明がありました。

また、文法変更を行わないとは言えパーサーへの変更を完全にストップする訳ではなく、バグフィックスはもちろんのこと、既存のパーサーで発見された曖昧性などの修正は積極的に行っていく方針を示しました。

コミュニティの力

一方、Ruby本体から外れる各種ツールの開発は、Rubyのコアチームとしてはスコープ外のことになってしまうため、コミュニティの力で現在あるツールの改善や新しいツールの開発を行ってほしい、とまつもとさんは述べました。

そのような活動を支える取り組みとして、いくつかの開発支援の仕組みを紹介しました。

また、RubyKaigiのようなカンファレンスの場で様々な人と会話をすることによって生まれる、新しいアイデアの重要性についても言及しました。2001年にフロリダ州のタンパで開催されたRuby ConferenceでのディスカッションからRubyGemsが生まれたエピソードを紹介しつつ、⁠この後のアフターパーティでもぜひテッキーな話をしてほしい」と話しました。

「Rubyという言語『だけ』でできることは、現代ではもう限られてしまっている」とまつもとさんは言います。より多くのコミュニティが力を結集することによってRubyをもっと良くすることができ、それこそがRubyコミュニティの力であると述べました。そして、⁠来年のRubyKaigiでもコミュニティの力を見せてもらえると考えています」と期待を寄せました。

Rubyの未来像

「未来のRubyについての話をしたいのですが、その前に過去の話をしましょう」と述べ、過去に考案したアイデアの振り返りから話し始めました。

Ruby2のアイデア

まつもとさんは、2004年頃に存在した「Ruby2」というアイデアについて触れました。これは実際にリリースされたRuby2.0とは異なり、当時Perl6やPython 3000(Python3.0)など多くのプログラミング言語コミュニティが歴史的な制約を取り払って新しいスタートを切る動きを見せていた頃に、新しいRubyとして考案されたものです。結果的にこのRuby2は実現されませんでしたが、互換性などの問題からコミュニティの分断を招く恐れもあったため、Ruby2が放棄されたことはRubyにとって幸いだったと述べました。

当時考えられていたRuby2のアイデアには以下のものが含まれていました。

  • Selector Namespace
  • キーワード引数
  • Method Combination
  • Unicodeサポート
  • パターンマッチング
  • Packages
  • JITコンパイラ

Ruby2のアイデアの現在

その後、Rubyは進化を続け、Ruby2のアイデアとして考案されたうちいくつかの重要な機能が実現されました。

  • Selector Namespace:一部がRefinementsとしてRuby 2.0で追加
  • キーワード引数:Ruby 2.0で追加(Ruby 3.0で位置引数とキーワード引数が分離)
  • Method Combination:Method PrependとしてRuby 2.0で追加
  • Unicodeサポート:Ruby 1.9で追加
  • パターンマッチング:Ruby 2.7で追加
  • JITコンパイラ:Ruby 2.6で追加

しかし、いまだに実現されていない機能もあります。

  • Selector Namespace:Refinementsで実現されなかった部分がある
  • Packages:実現されていない

これらの実現されていない機能のうちSelector Namespaceについては、今回のRubyKaigi 2024内のNamespace, What and Whyのセッションで実現に向けた提案が行われました。つまり、Ruby2として20年前に夢見た未来のRubyのパーツが今やほぼ揃うという状態になっています。

そのセッションでの提案に対し、⁠これがちゃんとRubyという言語に入ったら、Ruby 4.0にしたほうがいいかなと思います」とまつもとさんが話すと、会場から歓声が上がりました。

地球環境に優しいRuby

Ruby2として20年前に考えたものがほぼ実現されたことを踏まえて、⁠実装ができるかわからなくても、ほしいものについて話しておくことで誰かが実現してくれるかもしれない」として次の新しい夢に触れました。

Rubyは開発者の幸福や開発の生産性には非常に注意を払ってきましたが、実行時の効率についてパフォーマンスは改善されてきたものの最優先の事項ではなかったと言います。現代において、データセンターで消費される電力などの資源を考えた「地球環境に優しいRuby」があっても良いのでは、と話しました。

地球環境に優しいRubyのアイデアとして、以下の2つの例を挙げました。

  • メモリ消費量の少ない実装:Rubyのメモリ使用効率を向上させる取り組み
  • AOTコンパイラ:Rubyプログラムを事前にコンパイルしてバイナリを生成する技術

AOTコンパイラは10年前には困難だったアイデアですが、現代のType Profiling、Type Signatures、Profile Guided Compilationなどの技術進歩によって10年前にはできなかったようなアプローチでAOTコンパイラを作れるのではないか、と考えているそうです。

これらの夢について、⁠興味を持った方は是非声をあげてください」と呼びかけました。

Rubyコミュニティへの謝辞

最後に、まつもとさんは「コミュニティのひとつひとつの働き、あるいは活動が、Rubyをまわしていると思います。本当に感謝しています。まさにRubyという言語の活動、私の活動は、Rubyコミュニティに支えられていると言っても言い過ぎではないと思います」とRubyコミュニティ全体のあらゆる貢献に感謝の意を示しました。

そして、RubyKaigiの参加者に向けて「今日感じた『Rubyはすごい言語だった』などの気持ちを胸に帰っていただき、是非次回のRubyKaigiにも来ていただければ嬉しいです」と締めくくりました。

おすすめ記事

記事・ニュース一覧