PHPerが見るRubyKaigi タイムテーブル Day 3

こんにちは！ Platform Divisionのうさみ(@tadsan)です！

連日お伝えしている「PHPerが見るRubyKaigi タイムテーブル」も最終日ですが、注目しているセッションについていくつかお話しさせていただければと思います。

Ruby Committers and the World

紹介文は次のような一文だけですが、日本にも世界にも数多くある言語カンファレンスの中で、RubyKaigiが特異的なコンテンツはこれです。

CRuby committers on stage!

念のために書いておくとCRubyというのは、みなさまが一番よく使われているであろうruby コマンドで起動できる、Ruby言語公式のC言語で書かれたRubyの処理系(インタプリタ)のことです。特別なRubyをインストールした覚えがなければ、それはCRubyです。

同じ意味の用語でMRI(Matz' Ruby Implementation)という用語もありますが、基本的に同じものを指しています。単にコマンド名の ruby と書いてあれば、これもCRuby = MRI = 公式のRuby言語処理系のことです。

わざわざCRubyやMRIと呼ぶのは他のRubyも存在するからで、Day 2のOpening KeynoteではJRubyの開発史についても語られていましたし、Matz本人が作ったmruby、最近発展著しいPicoRubyなどもあり、言語としてのRubyは単一のものではなくなっています。

さておき、Rubyの開発者は世界中に居ますが、その中でもRubyのオリジナル作者である「Matz」ことまつもとゆきひろ氏をはじめとして日本人コミュニティが非常に大きな役割を果たしていることは間違いないでしょう。

「コミッター」とは、Rubyのソースコードリポジトリにコミット(GitHubへのPush)をする権限を持った開発者のことです。プログラミング言語についての意思決定にはさまざまな方式がありますが、Rubyの意思決定には多くのコミッターによる議論を経るものの、最終的な意思決定はまつもとゆきひろ氏が下す体制になっています。

このような少数の決定権者がプロジェクトの意思を決定する体制はBDFL(慈悲深き終身独裁者)と呼ばれます。もっとも有名な事例として、RubyのほかにはLinuxにおけるリーナス・トーバルズの存在も挙げられます。

ja.wikipedia.org

そのようなこともあり、毎年日本で開催されるRubyKaigiには日本中・世界中のRubyコミッターが一堂に会する機会でもあります。企業に所属しながらRubyに貢献している方もいますが、Rubyの開発プロジェクトとしては基本的にボランティアで、各コミッターは自分の興味関心のある課題に取り組んでいます。

RubyKaigiの目玉コンテンツである「Ruby Committers and the World」は壇上に居並ぶRubyコミッター各位が持っている課題について聴衆に向けて紹介したり、議論を行う時間です。場合によってはRubyの将来に向けた何らかの意思決定が行われることもありうるかもしれません。

また、PHPについては歴史的にBDFLモデルではなく、「RFC」と呼ばれる提案書に基いた投票に基く意思決定が行なわれています。そのため、RubyとPHPでは言語を進化させるメカニズムもまったく異なるのが興味深い点です。

Ruby Releases Ruby

rubykaigi.org

Rubyや、RubyのライブラリホスティングサービスであるRubyGemsを始めとする様々なエコシステムの運営に広く長く携わっているhsbtさんの発表です。

プログラミング言語のリリースには新機能の追加といった華々しい要素だけではなく、脆弱性を含むさまざまな不具合対応などの要素が含まれています。特に「ゼロデイ」と呼ばれる未公表の不具合が公開されると突如として世界中の稼働中のシステムが脅威に晒されることになるため、DebianのようなOSのパッケージレジストリとも緊密に連携しながら慎重に修正バージョンのリリースの調整なども行う必要が生じます。

このようにさまざまな作業や調整を伴うリリースエンジニアリングには世界中で様々な人々が取り組んでいますが、日本国内で見るとやはり日本発で国際的に利用されて知見が蓄積されているRubyは直接的に学ぶことが大きくあります。

PHPにおいては高町咲衣さんが2024年末にリリースされた8.4シリーズのリリースマネージャ(ルーキー)を務めているのが記憶に新しいところです。PHPではリリースマネージャは、ベテラン1人とルーキー2人のチーム体制になっています。

qiita.com

さて、これまでRubyやPHPといった言語ではユーザーコミュニティによって公開されているライブラリを広く活用して開発することが一般化しており、業務システム開発などでも珍しいものではなくなっています。昨今取り沙汰されているのが、サプライチェーン攻撃と呼ばれる言語や再帰的な外部依存などを含めたエコシステム全体への侵害による脅威です。

シンプルな自動化に留まらないようなリリースエンジニアリングについて深い話が聞けることを楽しみにしています。

(Re)make Regexp in Ruby: Democratizing internals for the JIT

rubykaigi.org

MakeNowJustことHiroya Fujinamiさんによる正規表現の話です。

私見ですが、プログラミング言語と正規表現の関係にはいろいろなものがあり、大別すると「ホスト言語の構文として正規表現を組み込んだもの」「ライブラリ的な機能として正規表現をサポートしているもの」があります。

前者にあたるものはAWK、Perl、JavaScript、そしてRubyなどです。後者は標準ライブラリに正規表現を持っているほとんどの言語と言えますが、前者と後者を分けるのが正規表現リテラルと呼ばれるものの存在です。

RubyとPHPを並べてみましょう。

# Ruby
p /^s+/ =~ 'str'

<?php

var_dump(preg_match('/^s+/', 'str'));

コードの構成要素自体は共通したもの '/^s+/' 'str' がある一方で、その並べ方( /pattern/ =~ subject vs preg_match($pattern, $subject) は大きく異なります。

コード内に直接書かれている 123 のような数字や 'str' のような文字列は、それぞれリテラルといいます。 /pattern/ のようなコードに直接埋め込まれた正規表現パターンは「正規表現リテラル」です。

Rubyの場合は、以下のようなコードはSyntax Errorになります。

# 常にtrueになるはず…？
if true
  p :ok
else
  # こっちが実行されることはない
  p /+/ =~ 'str'
  # + は /a+/ のように書かなければいけないので不正
end

一方で、PHPのコードはSyntax Errorではありません。

<?php
if (true) {
    var_dump('ok');;
} else {
    var_dump(preg_match('/+/', 'str'));
}

PHPで書かれた正規表現はあくまで文字列で、 preg_match() という関数に渡されてから初めて正規表現として意味を持つからです。これはPythonも同様で、正規表現機能はreという標準モジュールによってライブラリ的に提供されています。

あえて表現するとPHPとPythonにとって正規表現はあくまで外付けで分離可能なパーツであり、Rubyにとっての正規表現は比翼連理とも言える不可分な存在であるということです。

PHPにとって正規表現が分離可能であるという事実は、実は既に何度も実行されたことのある例でもあります。最初期のPHPのコードには、PHP/FI 2.0の reg_match() またはPHP 3.0以降のereg() という関数がありましたが、これはPOSIXのERE(拡張正規表現)と呼ばれるパターンが実装されていたものですが、PHP 7.0以降は廃止されてPCRE2というPerl風正規表現ライブラリが提供する preg_match() 系関数への移行が推奨されることになりました。

ではRubyではどうでしょうか。Ruby 1.8まではGNU regexベースに改造された正規表現エンジンでしたが、1.9で「鬼車」(libonig)と呼ばれる正規表現エンジンに置き換えられました。これは日本人のK.Kosakoさんによって開発されたもので、Shift_JISなどのエンコーディングも対応、Perlから取り入れられたものを含む高機能なものでした。

一方で鬼車は開発が停滞していた時期があり、Ruby 2.0で鬼車から派生した鬼雲という実行エンジンに切り替えることになりました。その後の鬼車はメンテナンス再開・マルチスレッド対応などの改善も行われましたが、2025年に正式に開発終了のアナウンスが行われました。

鬼雲はRuby向けに手が入ったものですが、内部構造としては手を入れにくいようで、発表のタイトルにも「Democratizing (民主化)」というフレーズが含まれています。

With the rise of JIT implementations like YJIT and ZJIT, rewriting Ruby primitives in Ruby has become a realistic way for optimization. This brings a dream of a pure-Ruby Regexp engine that works with JIT and integrates naturally with Ruby features (e.g., timeouts).

However, turning this dream into a production-ready reality faces a massive hurdle: compatibility. To replace Onigmo, we must replicate its exact behaviors, which is notoriously difficult. From my experience, the hardest barriers to a compatible reimplementation are the parsing and character class semantics.

I propose a pragmatic solution: exposing Onigmo's parser and character class logic as Ruby APIs. This democratizes the engine, offloading the complexity of compatibility to C while allowing us to focus on rewriting the matching logic in Ruby. I will demonstrate a PoC and discuss the future of a hackable, JIT-friendly Regexp engine.

YJITやZJITといったJIT実装の台頭により、RubyのプリミティブをRubyで書き直すことが、現実的な最適化手法となってきました。これにより、JITと連携し、Rubyの機能（タイムアウトなど）と自然に統合できる、純粋なRuby製の正規表現エンジンの実現という夢が生まれました。

しかし、この夢を実用化可能な現実にするには、大きな壁が立ちはだかります。それは互換性です。Onigmoを置き換えるには、その動作を完全に再現する必要がありますが、これは非常に困難です。私の経験から言うと、互換性のある再実装における最大の障壁は、構文解析と文字クラスのセマンティクスです。

私は、Onigmoのパーサーと文字クラスロジックをRuby APIとして公開するという、実用的な解決策を提案します。これにより、エンジンの民主化が図られ、互換性の複雑さはC言語に委ねられる一方で、マッチングロジックのRubyでの書き直しに集中できるようになります。概念実証（PoC）を実演し、ハッキング可能でJITコンパイルに対応した正規表現エンジンの将来について議論します。

ここで提案されているのは鬼雲が提供している正規表現パターンの構文解析などをライブラリとして利用可能にして、正規表現のロジックそのものはRubyで表現しようということです。

PHPで利用されているPCREのような正規表現ライブラリは有限オートマトンとしてJITコンパイルすることでパフォーマンスの最適化が実現されています。Rubyにおいてもこれらの試みに実用の道筋が立てば、より深いレベルでRubyの言語およびランタイムと統合ができそうです。

また、現在発展著しいJITの技術を応用して正規表現によるパターンマッチングの最適化も恩恵は大きいかもしれません。