2024年5月15日から17日まで、沖縄県那覇市の那覇文化芸術劇場なはーとでRubyKaigi 2024が開催されました。3日目の基調講演はRubyの作者である、まつもとゆきひろさんが登壇し、
まつもとさんは、Rubyの良さ、Rubyをより良くするための4つの側面、Rubyの未来像について話しました。
Rubyの良さ
「Rubyは本当に素晴らしい言語で、これを日本語で自画自賛と言います」
楽しい
まず最初にRubyの良いところとして、コードを書いていて楽しいという点を取り上げました。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は遅いと言われていることがありますが、現在のRubyは以前に比べて高速化されていると強調しました。
多くの大企業で利用するのに十分な速度で実行できるようになっており、例えばGitHubやShopify、SquareなどもRubyで動いています。なかでもGitHubは他言語でのソフトウェア開発にも利用されており、そのことからもRubyは非常に大事であるとまつもとさんは言います。
以上の観点から
Rubyをより良くするための4つの側面
前述のとおり、まつもとさんは
1. VMのパフォーマンス
「プログラマーはみんな速い言語が好き」
2007年にRubyの新しいバーチャルマシン
その後さらなるパフォーマンス改善を求めて2018年にMJITが導入されました。これはアメリカで開催されたRubyConf
2014のキーノートでまつもとさんが発表した
そこで、より実効性のあるパフォーマンス改善を目指し2022年にYJITが導入されました。Lazy Basic Block Versioningというアルゴリズムを採用した、より高速なJITコンパイラです。現時点ではRustで実装されています。これにより、Railsアプリケーションにおいて1.
さらに、Rubyのコアチームにとって頭の痛い課題であった古いRubyが使われ続ける問題も、YJITの導入によって改善しつつあると言います。
「RubyのVMを今後も高速化し続けることによって、Rubyはより偉大になっていくと考えています」
2. メモリのパフォーマンス
続く2つ目のトピックもパフォーマンス改善に関する話題となりましたが、今度はメモリ消費の側面からです。
VMには唯一と呼べるボトルネックが存在しないため、複数のアプローチでパフォーマンス改善を行う必要があり、その一つにメモリ関係の問題があるとのことでした。
Rubyにおいてはこれまで、オブジェクトのヒープの圧縮やメモリ割り当てのサイズを可変長にすることでメモリの消費効率を上げる、Object Shapeを用いてインスタンス変数へのアクセスを効率化する、その他GCの様々な改善を行うことによってメモリのパフォーマンス改善を行ってきたと言います。
現代のWebアプリケーションではメモリがボトルネックになりやすく、アプリケーション実行のためにより多くのメモリを必要としています。Rubyがより省メモリで動くようになれば、今までメモリに割いていたお金を開発効率の向上などのより有意義な活動へ充てられる、とまつもとさんは述べました。
Rubyをより省メモリにすることによって、Rubyをより偉大にできる、と結論付けました。
3. 並列実行によるパフォーマンス
「3番目の要素はですね……大体想像ついてますよね？」
Rubyが誕生した1994年当時の時代背景もあり、当初はマルチコアのCPUを想定した作りになっていませんでした。Rubyにはかなり早い時期からThreadが導入されていたものの、これは処理パフォーマンス向上を意図しておらず、マルチスレッドの実装をシンプルに書くことを主な目的としていました。その流れを汲んだ関係で、現代のRubyにおいても大量のThreadがパフォーマンスの向上に寄与することはないと言います。
一方、現代のプログラミングにおいて、
現在のRubyでコンカレンシーを担保する方法として、Unix系OSのプロセス・
- Thread：GVLがあるためマルチコアでは使いづらい
- （Unix系OSの）
プロセス：コンカレンシーを担保したいときに向くが、生成コストが重く、プロセス間の通信にもコストがかかる - Fiber：I/
Oのためのデータのコンカレンシーを確保したい場合に向くが、マルチコアが使えない - Ractor：
（まつもとさんの見解として） 正直なところ、まだプロダクション利用を広く勧められる段階ではない
また、今後の展望として、以下のものを紹介しました。
- M:Nスレッド、Rubyスレッドの数とネイティブスレッドの数を独立させる
- より軽量なRactorを目指す
- RactorローカルのGCを導入する
- Fiber Schedulerを導入する
Rubyがコンカレンシーを活用することによってパフォーマンスが向上し、並列実行を前提としていてもシンプルにコードを記述できるようになることでRubyがより偉大になっていく、という言葉でトピックを締めくくりました。
4. 開発者のパフォーマンス
最後のトピックは開発者のパフォーマンスについてです。
ソフトウェアの実行効率はとても重要な一方、開発者のパフォーマンスに目を向けることも非常に重要と考えている、とまつもとさんは述べました。
かつて、プレーンなテキストエディタでプログラミングを行っていた時代に比べ、現代においてはシンタックスハイライトなどの各種ツールによるサポートを受けることが当たり前になっています。
そのような各種ツールが目的を達成するためには、ツール自身がRubyのコードを解釈する必要があり、そのための大事な役割を担うのがパーサーです。現在、Ruby本体が使っているパーサー、ツールが使っているパーサーそれぞれが独立して開発されているため、大変な苦労があるそうです。そこで、
その候補として、手書きでパーサーを実装しているため処理効率の良いPrismと、形式的な定義からパーサーを生成するため正しさの観点で魅力的であるLramaを挙げました。
現時点では、Universal Parserの外部に対してのインターフェースは基本的にPrismのものをベースに採用することとし、一方でRuby本体のUniversal ParserのコアとしてPrismを採用するかどうかはまだ保留にしたいとのことでした。
まつもとさんは、この2つのパーサーに健全な競争をしてほしいという意向を示しました。
さらに、原則としてRubyへの文法変更を行わない
具体的な期間としては未定としつつ、2024年いっぱいから2〜3年程度の幅で、概ね1年程度を目途として考えていると説明がありました。
また、文法変更を行わないとは言えパーサーへの変更を完全にストップする訳ではなく、バグフィックスはもちろんのこと、既存のパーサーで発見された曖昧性などの修正は積極的に行っていく方針を示しました。
コミュニティの力
一方、Ruby本体から外れる各種ツールの開発は、Rubyのコアチームとしてはスコープ外のことになってしまうため、コミュニティの力で現在あるツールの改善や新しいツールの開発を行ってほしい、とまつもとさんは述べました。
そのような活動を支える取り組みとして、いくつかの開発支援の仕組みを紹介しました。
また、RubyKaigiのようなカンファレンスの場で様々な人と会話をすることによって生まれる、新しいアイデアの重要性についても言及しました。2001年にフロリダ州のタンパで開催されたRuby ConferenceでのディスカッションからRubyGemsが生まれたエピソードを紹介しつつ、
「Rubyという言語
Rubyの未来像
「未来のRubyについての話をしたいのですが、その前に過去の話をしましょう」
Ruby2のアイデア
まつもとさんは、2004年頃に存在した
当時考えられていた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内の
そのセッションでの提案に対し、
地球環境に優しいRuby
Ruby2として20年前に考えたものがほぼ実現されたことを踏まえて、
Rubyは開発者の幸福や開発の生産性には非常に注意を払ってきましたが、実行時の効率についてパフォーマンスは改善されてきたものの最優先の事項ではなかったと言います。現代において、データセンターで消費される電力などの資源を考えた
地球環境に優しいRubyのアイデアとして、以下の2つの例を挙げました。
- メモリ消費量の少ない実装：Rubyのメモリ使用効率を向上させる取り組み
- AOTコンパイラ：Rubyプログラムを事前にコンパイルしてバイナリを生成する技術
AOTコンパイラは10年前には困難だったアイデアですが、現代のType Profiling、Type Signatures、Profile Guided Compilationなどの技術進歩によって10年前にはできなかったようなアプローチでAOTコンパイラを作れるのではないか、と考えているそうです。
これらの夢について、
Rubyコミュニティへの謝辞
最後に、まつもとさんは
そして、RubyKaigiの参加者に向けて