Artichoke Rubyの終了について

2025年11月3日、私はArtichoke Rubyをアーカイブしました。2025年11月の残りの期間で、@artichoke GitHub組織の他のほとんどのリポジトリもアーカイブしました。これはずっと前から行うべきでしたが、プロジェクトを終了することは、ハッカーニュースのコメンターが正しかった、つまりほとんどの代替Ruby VMはいずれ勢いを失うということを認めるような気がして、長い間抵抗していました。Artichokeを始めた理由Artichokeは「Rubyを修正する」という壮大な計画として始まったわけではありません。それはおもちゃとして始まりました。私はルーブ・ゴールドバーグ・マシンを作りたかったのです。MonacoエディタのUIでRubyコードを書き、そのRubyがSCSSを生成し、Tokio HTTPサーバーを通じてページを動的に再スタイル設定できるようにするものです。そのために、mrustyクレートのmrubyへのバインディングに手を伸ばしました。それらのバインディングは機能しましたが、エッジが粗く、時折クラッシュすることもありました。（公平に言えば、それは難しいことをしていたのです。）一つのことから次のことへと進み、UIのおもちゃを作る代わりに、mrubyをストangler-フィグパターンで置き換え始めました。これは、Rust実装で徐々にピースを置き換えていく手法です。Martin Fowlerのストangler・フィグパターンの説明は、このアイデアをよく捉えています。そのプロセスは「mrubyの酸化」となりました。それは常に探求的なものでした。私はArtichokeがCRuby、JRuby、またはTruffleRubyと競合するとは決して信じていませんでした。私はそれをどこまで押し進めることができるかを見たかったのです。元の意図は、プロジェクトのVISION.mdに今も捉えられています。それが現実味を帯びた瞬間は、Regexp（mrubyにはなかったもの）を実装し、それをRubyConf 2019で発表したときでした。ステージに立ってRustバックのRuby実装について話すことは、この実験を具体的なものにしました。私が構築したもの6年間で、Artichokeは本来あるべき姿よりもはるかに現実的なものになりました。私はいくつかのことに誇りを持っています。純粋なRustによる仕様準拠のStringArtichokeは、bstrクレートの上に構築された、100% Rustで書かれた完全に仕様に準拠したString実装を出荷しました。その努力はRustエコシステムにフィードバックされ、bstrのAndrew Gallant氏の発表ポストで言及されたことに感謝しています。Stringを書くことは、Rubyのエンコーディングセマンティクス、バイト境界と文字境界、グラフェムの仮定、そしてMRIがエッジケースでどのように動作するかという微妙な方法を理解することを私に強いました。それは基礎的な作業でした。モジュール化された、機能指向のVMアーキテクチャArtichokeは、Cargoフィーチャーとクレートのモジュール性に大きく依存していました。アーキテクチャは意図的に分離されていました：VM関連の懸念（artichoke-*）コアデータ構造（spinoso-*）VM内部とグルー（mezzaluna-*）純粋なユーティリティ（scolapasta-*）この構造はARCHITECTURE.mdに文書化されており、matklad氏のレポジトリアーキテクチャの文書化に関する考え方に影響を受けています。目標は疎結合でした。必要な機能だけを備えたインタープリタを組み立てることができました。ネイティブ機能はトレイト駆動でコンポーザブルでした。GILが存在する理由を学ぶプロジェクトの最も教育的な側面の一つは、初期のアーキテクチャ上のショートカットを解きほぐすことでした：インタープリタの状態をRc<RefCell<_>>でラップすること。PR #442は巨大なState構造体を分解しようとしましたが、その初期の決定はコードベース全体に感染していました。それはそのままではコンパイルされず、最終的に数十の小さなリファクタリングを生み出しました。PR #670はRc<RefCell<_>>の削除を完了し、インタープリタを明示的な&mut Artichokeの借用を中心に再配置しました。その移行により、ほぼすべてのインタープリタAPIが&mut selfを取るようになり、コードベースの構造が完全に再構築されました。借用チェッカーは、ミュータビリティの境界を痛いほど明確にしました。mrubyの&mut Interpを渡す設計は、ダイナミック言語ランタイムにおけるミュータビリティの場所とヒープの場所を反映しています。このプロセスを経ることで、YARVとCPythonがGILのようなものに収束する理由が明らかになりました：インタープリタにおけるエイリアシングと共有ミュータブル状態は、そうでないとモデル化するのが非常に困難です。Ruby言語はCとPOSIXの仮定と密接に結びついています。配列は連続したバッファでありたいと望んでいます。コア構造をハイパースペシャライズしようとする試み（Scalaマップのように空/単一/二要素のケースを最適化するなど）は、MRIが世界をモデル化する方法とは一致しないように感じられます。Artichokeは最終的に、それに抵抗するのではなく、その現実に傾倒しました。教育Artichokeは、私にRustを深く学ばせました：unsafeコード、FFI境界、ポインタのライフタイム、トレイト設計、ランタイムアーキテクチャ、ストレス下での借用セマンティクス。その教育だけでも、この実験は正当化されました。なぜ終了するのか劇的な理由はありません。単に時間がなくなったのです。年齢を重ねるにつれて、私の焦点は仕事と家族に移りました。OpenAIは最高の意味で要求が高く、言語ランタイム（実験的なものであっても）を維持する機会費用は高すぎました。喜びの微妙な変化もありました。Artichokeの魔法の多くは、自分でRustを「手作業で」学ぶことにありました。私はそれを達成しました。今では、unsafe Rust、低レベル設計、FFIに関する深い経験を持っています。その基盤は、コーディングエージェントや最新のツールを効果的に使用できるようにしてくれますが、それは「これを理解できるか？」という当初の火花が薄れたことも意味します。互換性のための苦労という現実もあります。Artichokeのmspecとruby/specはMRI 2.6.3をターゲットにしています。アップストリームRubyの追随は終わりのない仕事です。仕様バージョンの更新、動作変更の調整、エッジケースの追跡は終わりがありません。そして、実際のユーザーベースがない（またはそれを育てる意欲がない）場合、その負担を背負う説得力のある理由はありません。Stringを完成させた後、次のコアクラスであるHashの実装を3年間始めなかったときに、終わったと知りました。次に何が起こるかArtichokeはアーカイブされましたが、消去されたわけではありません。リポジトリは公開されたままです。アーキテクチャのドキュメントはそのままです。コードは引き続き研究、フォーク、または埋め込みが可能です。私はアクティブな開発を再開する予定はありません。過去のアップデートやプロジェクトの履歴については、ツイートは@artichokerubyで引き続きご覧いただけます。もしあなたが本番環境でArtichokeに依存しているなら、CRubyまたは他のアクティブにメンテナンスされている実装への移行パスを計画すべきです。Artichokeは互換性アップデート、新機能、またはセキュリティパッチを受け取りません。それは、当初の目的を達成したという意味で完了しています。感謝アーカイブすることは失敗とは感じません。Artichokeは私にとってその目的を果たしました。それは境界を押し広げました。それは成長を強いました。それは私が誇りに思う成果を残しました。そして、毎月のDependabot PRをもうレビューしなくて済むのは良いことです。🤖イシューを報告してくれたり、パッチを送ってくれたり、質問をしてくれたり、あるいはRustでRuby実装を構築することが試みる価値があることだと信じてくれたすべての人に感謝します。共同メンテナーのchoznerol氏（GitHub, @choznerol）とb-n氏（GitHub, @NZchicken）に特別な感謝を。読者の皆さんに何か持ち帰ってほしいことがあるとすれば、それはこれです：物事を構築してください。奇妙なものでさえ。永遠に続かないかもしれないものでさえ。構築するという行為はあなたを変えます。