RubyKaigiというものに行ってきました。 プログラミング言語「Ruby」好きが集まる最大規模の催し、ということで、海外からの参加者もたくさんいました。 どうやら毎年、全国津々浦々さまざまな場所に開催地が置かれる、とのことで、遠路はるばる同じ趣味の者どもが日常から切り離された広い空の下へ集結してしまうことによる、隔離された非日常空間、束の間のお祭り騒ぎ、ーーみたいな雰囲気が自ずと醸し出されているのが独特です。 Rubyといえば、日本人のMatz氏の作で、中心的な開発者は今も日本人に多い、ということで、日本人ユーザーの数は圧倒的です。 僕はといえば、ずいぶん昔はRubyを好んで使っていたんですが、現在では仕事ではまったく使わなくなってしまった人間の一人です。周囲にはそのような変遷を辿った人間は珍しくありません。 Rubyについて思い出すと、やはりWeb2.0 だとか 言われていた時代が嫌でも想起されます。あの頃、故TwitterとかもRuby on Rails で書かれていたし、Webサービス開発ではRubyが本当に流行っていたと思う。いや、流行っていたというより、エンタープライズ業務アプリケーションOOP界隈の「正しさ」に唾を吐き、積み重なった手段のための手段すべてを足蹴げにして未踏の道を行くカウンターカルチャー、であると同時に、ルールではなく直感に従う、直感的な書き心地こそが生産性である、そんな精神をWeb開発界隈で花開かせた急先鋒の一角だった、と思います。Rails以前・以降では、Webアプリケーションフレームワークの美意識はあきらかに変わりました。いや、美意識というものが発見されました。足元の地面をよく見ると、屍と化した大量の『〇〇言語で書かれたRails』が堆積した土の上を我々は歩いています。 あれから時代は移り変わり、あっちへ行った振り子がもう一度逆向きへ戻ってきているような気がしますが、そのことは今は忘れましょう。 あの頃は、とくに社会でなんら役に立たなそうな僕のような人間も、ぺぺぺっとWebサービスをつくっているだけで、なにか社会的に意義のあることをやっている、そんな幻覚をみんなで見ていました。Webサービスのありかたをデザインすることは、とっても哲学的な思想の社会実装だ、と、信じられていました。まじです 。気概は持ちながらも、「そんなご大層な仕事じゃないと思うけどな…」と頭のどこかで思ってたし、たぶん、いまでも幻覚を見ているのかもしれません。早く夢から冷めないと。 Rubyの不思議のひとつは、いったいどんな匂いを嗅ぎつけたのか、コンピューターに興味があるというより、詩想のある文章や漫画でRubyについて語りだす、文才のある人達が現れては消えていったことだと思います。まじであいつらすごすぎる……あれはなんだったのか。今だにわかりません。彼らは一体、どこへ行ってしまったんでしょう。 振り返ると、現在のユーザーと比較しても劣らない程度には、当時の僕はRubyが好きだった方かもしれません。 ## Ruby使わなくなった理由 では、なぜ使わなくなったのか。僕にとって、その理由は曖昧なものではなく、それなりに明確です。普通のアプリケーション開発の仕事をしていて、時代の変遷を辿っていっている人々にとっては言うまでもないことかもしれません。 - サーバサイドプログラミングの文脈 - 非同期 I/O エコシステムがない - 近年使われてる言語と比較して、サーバー台数が嵩みがち。一桁違ったりする。 - (GILの影響で プロセス forkする慣習 & メモリ食いのコンボの影響ももちろんあるけど 非同期I/Oがないことがつらい) - ユーザーからみてコネクションつなぎっぱなしのプロトコルが本番でまともにスケールしない (I/O がスレッドをブロックするため) - いわゆるC10Kとな当時言われてた問題。 - ユーザに対してそれなりにリアルタイム性のある機能を提供したくなることはとくに珍しくなくなったし、できると用途が広がる感覚があるが、Rubyはこれが苦手。 - SSE とかまともに使えると嬉しいですやん。RailsのActionCableもWebSocketですやん。 時代はgRPC Stream ですやん。http2ですやん。3ですやん。 - オンラインゲームのプロジェクトをやっていた頃、けっこうRubyが使われている会社にいたが、この用途ではRubyはまったく使えなかった。 - 同じ頃、ちょうど node.js、Golang が出てきてここを解決していたので人が流れていた。 - サーバ文脈でGoが「速い」というとき、CPUバウンドな性能でなく、何も考えなくてもI/Oが非同期になっているからスループットが出る、という意味でしかないように思われてならない。 - Rails + 非同期I/Oができる言語を組み合わせる、という構成も昔はみかけたが、結局は言語を全部統一する力学が働いていく。 - Ruby の場合、3あたりで万を持して「Concurrency」の機能が追加されるとされていたが、追加されたRactorは、「Concurrency」というよりは「Parallelism」のほうを解決している。(性能面での意義はGILが外せることだけという意味で） - この問題と対峙しているRubyコア機能として、 FiberとFiberScheduler がある。 - RactorをConcurrencyと言ったり、Fiber を軽量スレッドと言ったりするのは、課題設定が若干ちぐはぐで、そのせいか一般Rubyユーザーもあまり問題を理解していないと思われる。 - 現在、Webサービス界隈で使われている大抵の言語はこの課題に取り組んでいる。 - Webサービスのクライアントがクロスプラットフォーム化し、ワークロードごとに分散する、みたいになるにつれ、鯖/蔵の間でデータモデルをどう共有するか、という問題が出てくる - 型定義を一次情報とした強力なコードファーストアプローチが理想系のひとつとして再発見される昨今。 - すくなくとも、 あとからテストを書く、あとからvalidationする、という手法よりも、実装を一次情報として、実装からスキーマを解決するほうが優れている。 - Ruby on Railsは 「設定より規約」なので、アプリケーションの実装をコードファーストなスキーマ宣言とするようなソリューションが生まれずらい。 - Webサービスが複雑化するにつれ、Web API というものを RESTfulにつくる意義が減った - 昔のWeb APIは「HTTPクライアントさえあれば誰でも使える」という思想があったからこそ、アプリケーションプロトコルをHTTPの仕様に後退させることに意義があった。 - 現在は、オープンなAPI とかも100%の確率で言語別のSDKやライブラリ経由で使うので、 RESTであるかどうかは使う側にとってはどうでもいい。 - 複雑なアプリケーションでは、CRUD以外の動詞が柔軟に使えるほうがよい - Railsは そもそも古のRPCを否定して RESTを推進した存在なので、再度の揺り戻しに興味なさそうにしている。RESTを前提にした規約やショートハンドで組み立てられてる部分が多い - クライアントサイドプログラミングの文脈 - js とか C# とか Rust とか Kotlin とか Swift とかDartとかMoonBitとか、クライアントサイドアプリケーション開発をターゲットとしている言語は、シングルスレッド非同期プログラミングのためのモデルを持っている。Rubyにはない。 - 実用レベルでは、キャンセル伝搬、エラー伝搬、を含めた非同期処理の合成ができてほしい。 - 開発体験の文脈 - Webサービス開発というものはある時期までは、決まったことを短い記法で書ける「スクリプト」であることが最高の生産性をもたらしていたのは本当だったかもしれないが、つくるものや扱うデータモデルや求められる体験が複雑になっていくにつれて、そうではなくなった。 - 複雑で大規模なコードベースの中を、依存ライブラリも含めて完璧に高速で解析できるかどうかで、生産性と使ってる道具への学習効率や理解のしかたが別物になる。 - Rubyは字面のよさを最高の優先度に置いてるのと実行時メタプログラミングでなんとかしがち 僕がRuby を使っている人々と話した範囲では、こうした課題感はあまり感じていないそうです。その辺は不思議に思っています。 ちなみに僕は、「型アノテーション」とか「async/await構文」とかをRubyに入れるべきだとはまったく思ってません。 ## RubyKaigi参加と登壇の目的 「Ruby使ってない」とか言いつつ、最近はゲーム開発の文脈で mruby をスクリプト言語として使う取り組みをしてます。今のところの主目的は個人制作です。 アプリケーション開発ではRubyが主役になることはなくなったものの、DSLみたいなもののレイヤーに使うにはかなり良い、というか、本来はそういった分野で光る言語ではあると思うんですよね。 アプリケーションへの組み込みというと lua の名前がよく出てきますが、僕としてはこの分野でもmrubyがもっと使われてもええんちゃう？ と思っています。とはいえ、mrubyを使ってみると躓く点は多くて、ゲーム制作界隈でも「mruby撤退してluaにするわ」という発言をしている者どもを複数名観測しているほどです。 そんなmrubyをC#環境で使いやすくするため、mruby vm をC#で再実装する、というのが最近の僕の取り組みです。 - [hadashiA/MRubyCS](https://github.com/hadashiA/MRubyCS) - [[Unityでmrubyスクリプティング]] 再実装とはいえ、mrubyのほぼ全ての仕様を網羅している上、Fiberも入っている、本家を上回るくらいのパフォーマンスが出ている、という意味では、それなりに成果が出た。というわけで、今回のRubyKaigiではこのテーマで登壇させてもらえることになりました。 RubyKaigi の存在は知っていたんですが、公式サイトはすべて英語だし、みかけた発表資料もすべて英語。英語じゃないと喋っちゃいけない会かな？　と、てっきり思い込んでたんですが、日本語での発表も大丈夫でした。知ってました？ やっぱり普段日本語でものを考えているので、その場のノリで思いつくまま話したり、聴いてくれている人の反応を感じたりするには日本語がいいよね。もし英語で話すことになったら、あらかじめ用意した台本を読むくらいが精一杯になっちゃいそうです。それは聴いてる側としてもつまんないだろうと思います。英語はイントネーションとかリズムがまったく変わるので、別人になれるかんじがおもしろいかもしれないけど。 どうもRuby界隈からは今のところ自分の活動に対しで芳しい反応がないようなので、成果を共有したり宣伝したりしよっかな、Unity + mruby ユーザ増えるきっかけになればいいな、というのが目的の半分。 もう半分は、mruby をアプリケーション組み込みで使うのに辛いところ、なんかそういう課題とかフィードバックする機会にしたい、という目論見もありました。ユーザー目線でそういうの共有することも一応、貢献だとは思うんだけど。 ## 参加してみての感想 ### Rubyコミュニティ Rubyを使っている人は本当にRuby、あるいはRubyコミュニティを気に入っており、好きだからここにいる、それを互いに確認し合っている、という印象を受けました。発表内容や、反応、雑談した人の雰囲気などから。 正直、C#も、使っている人はやたら「C#最高〜」とか言っていて、外側からは冷たい視線を送られており、肌寒い。という点は似てるかもしれませんが、それとも少し違っている。 C#の場合、ただ単に「強いから」という理由で使われている節があると思うんです。 現在、アプリケーションレイヤーで使われがちな言語はどれも極端に癖が強いと思います。(例は挙げない) C# は今となっては最高とまでは言えないが次点くらいの水準のまともなセマンティクスをもち、性能、エコシステム、開発環境、に最高レベルの投資がなされており、かつ、非同期プログラミングモデルをもち、かつ、鯖/蔵 用途で使えます。この条件に当てはまる言語がほかにない、とは言いませんが、成熟度で言えば非常に先行している。だから使っている。もしも、似たバランス感覚でもっと先行する言語がほかに目の前に出てきたら、去るC#使いは多いかもしれません。ドライな関係です。AppleのSwiftがもっといろいろな環境のまともなIDEでサポートされて、クロスプラットフォームゲ開発で使えたら、C#じゃなくてSwiftを使いたいよ。おれ。JVMのビルドパイプラインとライブラリ群が10倍洗練されて、パフォーマンスにもっと注力されていたらC#じゃなくてKotlinを使ってたかもしれないよ。おれ。 Rubyユーザーの場合、Rubyが好き、という雰囲気が強いと思います。他言語ユーザーとしての自分の感覚では、アプリケーション開発の文脈から見ると噛み合わない部分や課題も出てきていると感じますが、僕が話してみた限りでは、そうした課題はあまり話題に上がらないみたいです。 昨今のOSSを利用する体験をしていると、ユーザーを拡大するとか、ある特定の用途を想定した実用性の追求に目標が置かれているとか、使われるために労力が割かれているのが当たり前のように感じてしまいますが、Rubyの場合、外側をあまり意識していない(そこをゴールに置いてない）のかもしれません。 https://x.com/yukihiro_matz/status/1861718603084750904 > Yukihiro Matz > @yukihiro_matz > ほら、そこにソースコードがあるじゃろ。で、疑問に思ったことを質問するんじゃ ふと大画面に映しだされたスライドを見ると、「WE LOVE RUBY (宝石)」みたいなことが書かれたスライドが表示され、 「Yeah〜」 「おおー」 「ぱちぱちぱちぱち」 と、盛り上がる、といった場面に何度も出会いました。ここまで手放しに愛されてるのはすごい。 mruby/PicoRuby関連の発表も多かったですが、工作そのものに強い情熱をもった者たちが「なんとこんな環境でもRubyが動く！」「これ全部Rubyっすわ」 「Year〜」 「おおおおおお」 みたいな感じで作品を持ち寄り、盛り上がっていました。僕も「おおー」って言っていた奴らの一人ではありましたが、ここではRubyは何かを達成するための手段である、というよりも、Rubyそのものが目的、Rubyで書ける状態に到達することそのものが目的になっている、という点が独特です。一般Rubyユーザーはこういうのも楽しに見に来てたみたいです。低リソースな環境でRubyを動かすための制約や、そもそも自作するということにまつわる技術的なチャレンジはおもしろい。とはいえRuby自体がゴールであることは暗黙の了解となっており、そこがゴールであることにはもはや説明のいらない人向け。ではあるかな。 Rubyの日本人コミッターと 日本在住Rubyユーザーはけっこうコミュニケーションを取りやすいらしく、距離感が近いみたいです。RubyKaigi常連たちは、セッション内容だけでなく「この人の話なら聴きたい」という感じで発表者ベースで追っているらしい。僕は界隈の人物をあまり知らなかったので、タイトルやDescriptionだけ見て回っていたんですが、結果として有名コミッターの発表をけっこう見逃していたかもしれません。抽象的なタイトルやニッチなテーマは、足を運ぶきっかけを掴みにくかったので。 Rubyの最新機能の発表についても、その機能への興味というより、Rubyの直しっぷりをドキュメンタリーとして体感できるような発表が人気だったっぽいですね。 ### Shopify勢の存在 周りは驚くほど「Ruby最高〜」って言っていて、割と現状のRubyは肯定的に見ているようでしたが、一方、Rubyの真っ当な進化を垣間見ることもできました。 印象に残ったのは「Shopify」という名前です。 タイトルや概要だけ見て興味をもった発表を聴きに行くと、発表者はだいたい「ぼくShopifyで働いてます」って言ってました。(まじです) Shopifyという組織は、リアルワールドでの大規模Rubyアプリ運用を背景に持ち、大規模Webアプリケーションサーバー開発における課題をRubyに持ち込んで、解決に取り組んでいるようです。 聞いた話では、他言語の先行するJITと同じコンセプトをもつ「ZJIT」もShopifyの開発チームによるもの、現行の「YJIT」もShopifyのチーム、MRubyCSでも使っているRubyの大統一パーサー「prism」もShopifyの人によるプロジェクト、 静的セマンティクス解析の統合基盤「rubydex」 (C#でいうRoslyn のCodeAnalytics 的な? ) もShopifyのチーム。 ついでにAsync gem や FiberSchedulerの取り組みで有名な Samuel 氏も現在はShopifyの所属。Falcon使ってんのもShopify。あれもShopify。それもShopify。 C#におけるMicrosoft、GoにおけるGoogle、JavaにおけるNetflixなどを彷彿させます。 ある時期、Rubyに追加されていく機能とかをみかけると「これってRubyでアプリケーション開発してる人がデザインしてるのかな…？」ていう疑問を持つことがあったんですが、Shopify勢の取り組みを見て、その認識は一部改められました。リアルワールドの課題が持ち込まれるのはRubyにとって良いことなんじゃないでしょうか。だってみんなWebアプリケーション用途で使ってるわけでしょ。ユーザー目線ではそうおもいます。 僕はRubyが用途に合わなくなったり性能問題にぶつかると「けっ」と捨てゼリフを吐いて使わなくなったわけですが、ShopifyはRubyに留まるという選択をし、Rubyを直す、という道を行っていました。その取り組みのレベルは非常に高いです。ここまでやれば、直せるんだ ーーこの事実に、函館の冷凍のカニで頭を殴られたかのような衝撃を受けました。 ただの利用者が技術者面していることが多い昨今ですが、自分の道具を深く使いこみ、高いレベルで複合的な改善ができるアイデアを持ち続けられる人が技術者だと常々思います。自分もそうありたいものですが… #### ZJIT 一般に、JIT が「むちゃくちゃ速い」とされている理由は、マシン語に変換されるから、という説明は半分に過ぎません。もう半分は、実行時にしかわからない情報を使ってホットパスを最適化できるから、です。 ZJITは、Rubyバイトコードをまず SSA IR 高レベル中間表現にし、そこからRubyセマンティクスを解析して最適化したあと、loweringして SSA IR 低レベル中間表現 → マシン語、というパイプラインを通る、先行する他言語と同等の仕組みをもつJITです。.NET じゃん。JVMじゃん。 現行のYJITは、Rubyをマシン語にするという偉業を達成していますが、最適化についてはまだのびしろを残しています。型特殊化とかはあるけど積極的なインライニングとかはないぽいです。つまり ZJIT でついに Rubyの実行時最適化への重い扉が開かれようとしてます。 Rubyという言語において、もしも実行時にしかわからない情報による最適化ができるなら、未踏ののびしろだらけです。 たとえばRubyでは、 2つの数値のうち大きいほうを返す式を、 ```ruby [a, b].max ```` とか書くことは日常茶飯事ですが、素朴に考えるなら、本来は単純な数値比較と分岐で済むはずの軽い処理が、Rubyっぽく書いてあるせいで 配列アロケーションとメソッドコールという重い処理と化してしまいます。ついでに、aもbもマシンにとっての数値ではなく、boxingされた値であり、実行時にしか型がわからない。もちろん、ここまで簡単な例だと静的解析だけでも除去できそうですが、実際、mrubyコンパイラだとこのコードはArray.newと .maxのバイトコードを吐きます。 もしエスケープ解析やObject stack allocation のような最適化が進めば、上記のようなコードもただの三項演算子と同等のコードにコンパイルできる、かもしれません。多段的なインライニングなどが進むと、もっと複雑な例も同様に畳み込まれ、結果として RubyっぽいコードがAOTコンパイル型言語に匹敵するくらい速くなる場合がでてきそう。 V8とおなじで、VM空間のすべての値は概念上はboxingされているはずで、boxingされた値を扱う境界では 最速にはなりえないとは思いますが、Rubyっぽい文法を維持したまま、いけるところまでいく最適化が入ると、その振れ幅でインパクトがあると思います。js とかよりワンライナーとか書きやすいしね。 型アノテーションを絶対に入れないRubyにとって、型の利点のひとつである最適化しやすさを、ZJITが実行時解析によって突破する可能性を示しているとも言えます。 実行時の型特殊化やエスケープ解析は僕のMRubyCS でもやってみたいわー、やろっかなーと思いました。 #### FiberScheduler Ruby界隈は、型アノテーションだけでなく、async/awaitのようないわゆる「function coloring problem」に拒絶反応を示しています。 たぶんそれもあってか、シンタックスだけでなくついでに非同期プログラミングそのものの導入にも慎重な文化です。 ここに切り込んでいっている試みがFiberScheduler です。 元々Rubyには「Fiber」という、Rubyコードを任意のタイミングで中断/再開できる機構がありますが、Rubyの標準ライブラリのI/Oはすべてスレッドをブロックする上、Fiberを外から操作するスケジューラがRuby自体にはないので、(よく考えたらなんでやねん) 用途が限定されてたとおもいます。 FiberSchedulerがすごいのは、既存のRubyのソースコードに変更を加えず、さらに言えば、既存のライブラリのAPIにも変更を加えず、I/Oをノンブロッキング化するところです。 路線としてはJava の Virtual Thread (Project Loom) と目的地が似てますが、Fiber自体は Cooperativeであるため、 もっと柔軟性があるかもしれません。 Rubyで「ソースコード一切変えない」縛りを化したまま、バランスをとる現実的な落とし処をみつけたアイデアは非常に優れていると感じました。もしも、「ライブラリのAPIは一切さわらずにI/Oをいますぐノンブロッキングにして〜」っていきなり言われたら「え？　無理です」と即答したくないですか？ 答えを見てしまうと仕組みは単純です。RubyのFiberは、コールスタックの奥深くの、ごく普通のシグネチャのメソッドからも `Fiber.yield` で サスペンドできるため、I/O する低レベルAPI の実装すべてにいちいち Fiber.yieldを挿入してあげれば、スレッドをブロックせずに中断→再開が一応コントロールできます。FiberSchedulerが設定されている場合、yieldしたあとで FiberSchedulerの実装がいつresumeするかを決める、ただそれだけです。あらゆる IO の根本を共通のAPI でまとめて 分岐を挿すのをやりきるのはそれなりにチャレンジングなのかもしれませんが。 僕もMRubyCS をやっていて、C#のasync/awaitシステムと Fiberを組み合わせるという課題に当たってましたが、FiberSchedulerみたいなやつをもっと早く思いついてたらよかったです。 FiberSchedulerは今日明日にでもMRubyCSにも取り入れようと思います。(Fiber自体は既に入ってるよ) ### パーサーとセマンティクス解析 ( TODO: この話題もいろいろ書きたい) ## おれの発表 僕の発表スライドです。  [mruby on C#: From VM Implementation to Game Scripting](https://speakerdeck.com/hadashia/mruby-on-c-number-from-vm-implementation-to-game-scripting) mruby 非常につらい。使いたいんだけどつらい。 ーーそんな問題意識から話を始めました。mrubyがもっと流行ってほしいので…。途中でふと時計をみると、その話で半分くらいの時間が過ぎていた。 結果的には、「クロスプラットフォームアプリケーション組み込みでなぜ流行りにくいのか」という問題設定は、聴いている人の関心とうまくつながっていなかったので、焦点を置くところを間違えていたと言えます。時代はPicoRuby。みんな ハードウェア組み込みで使ってるし、知らんがな、という感じでしょうか。 順番も間違えたかもしれません。ゲームとかアプリケーション組み込みでもRubyはいいんだヨ。Ruby最高ダヨ〜 というメッセージをまず発信する、なにができるか見せるべきだったかもしれないですね。 「Rubyが ホットリロードもできるヨ!! ゲームをプレイしながら内容をRubyで書き換えられるヨ!! WE LOVE RUBY! (宝石の絵文字)」 「わーわーわー」 これでした。やるべきだったのは。 ランタイム実装のパフォーマンスで工夫したこととか、非同期メッセージパッシング合成チェインの設計の話題とかもすごく話したかったんですが、その前に必要だったのはデモですわ。デモ。 話したいことはけっこうたくさんあって、焦点を絞り切れていなかったし、いったい何を求めて人々がRubyKaigiに来てるのかも掴めてなかったので、事前に準備の質を上げるのが難しかった。 もし次回があったらいろいろ改善したいです。 話している中で、やっぱり自分は 非同期プログラミングがまともにできることをかなり重視していて、それによって言語の用途が広がる、という議論を、非同期に価値を見出してなさそうな Ruby ユーザーにもふっかけたい、そんな気持ちも出てきました。この辺の話はもっとちゃんとしたかったですね。 Golangとかがクライアントサイドアプリを書く用途で使われない理由は、プリエンティブなスケジューラとチャンネルだけでは、非同期用途ですべての問題を解決してるわけじゃない、ていうのもあると思うんですよね。 Rubyがasync/awaitとかそっち系の構文に入れないのは全然いいと思うんですけど、なんらかの方法で 同じようなことできないと、現代のアプリケーション開発でよく使われてる言語と比較すると用途が狭いんだよね、時間が足りなくなったのでその辺のページはごっそり飛ばしてしまいました。 せっかくWeb界隈と地続きであるRuby界隈で話す機会を得たので、Web界隈でほとんど無視されている C# をもっと知ってもらうきっかけになったらいいな、という思いもありました。が、そこはそんなに伝わらなかったかな。振り返ってみると、JRuby Guy の存在、そしてZJITがJVMを引き合いに出していたことで、圧倒的に「JVMすげえ」という感想をみかける三日間でした。.NET は JVM と匹敵するくらいの性能ある + 非同期エコシステムくそつよい、このキーワードだけでも覚えてもらえてたらいいのだけど。 壇上を降りた途端、JRuby開発者 の人がめちゃめちゃ気さくに話しかけてくれて嬉しかったんですが、英語ができないので、 「あ、あのあのあの…えっとえっと…… あ、あ、さんきゅーさんきゅー」 となって適当な返ししかできなかったのが非常に残念でした。JVM と .NET の話とか本来はいろいろしたかった。ていうかするべきだった。やっぱ英語は話せるべき! 録画がのちほど公開されるらしいけど、怖くて見れねえ ## そのほかの発表の感想 (思い出したら追記します) ### Day1 #### [The Journey of Box Building - RubyKaigi 2026](https://rubykaigi.org/2026/presentations/tagomoris.html) Rubyのモンキーパッチも含めたクラス/メソッド定義を隔離できる新機能の話。ここに Box という名前を与えるのがRubyっぽいといえばRubyっぽい。 同一プロセス内で複数アプリをーー という話もあったので、V8 の isolateとかcontextとかと少し似ているとみせかけて、メモリ領域を隔離するというより、コード定義を隔離するものらしい。Box を指定して そのなかだけに require とかできる。とのこと。 一般Rubyユーザーからすると そこまで 使い処があるのかはわからないけど、やたら組み込み型を拡張するRuby界においては大きな変化なのかもしれない。 言語機能としてこういうのが入ることは、中身の構造も使い勝手も微妙に複雑化していくとは思うけど、変化しつづけて落とし処をみつけ続けていく大変さが想像されます。 個人的にはこの機能自体にはそこまで関心はないですが、 この発表の感想を発信してる人は多かったですね。 #### [Funicular: A Browser App Framework Powered by PicoRuby.WASM - RubyKaigi 2026](https://rubykaigi.org/2026/presentations/hasumikin.html) このテーマはけっこう興味を持ちました。 Cで書かれているmrubyランタイムはemscripten で WASM にコンパイルできるので、要するにそれがpicoruby.wasm てことらしいです (たぶん)。Unityでも mruby vm をブラウザで動くときにWASMにコンパイルしてるのでほぼ一緒といえば一緒です(たぶん)。picoruby.wasmの場合、 esmモジュールとしてパッケージが公開されておりすぐ使える状態らしい。 発表されたFunicularというのは、ブラウザで動く mruby vm の上で動く、RubyだけでSPAみたいなのを書けるライブラリとのこと。hyperscriptみたいな HTMLツリー構築ヘルパーと、あと React っぽいVDOM も実装されてるそうです。(最近は VDOM より signal の DOMバインディングのほうが軽くなったりしないのかな?) ブラウザでRubyが動くってことで、デモで会場が湧いてました。とくに ブラウザの開発者ツール上(だったかな?) で rubyデバッガが動いているのが目を引きます。これは見てるほうも「おー」ってなるし、デバッガがあることの便利さも見てわかる。 デバッガはMRubyCS にも入れよう。と強く思いました。 そしてもおれもデモをすればよかった、と思いました。 実際、Rubyをこういう用途でWASMで使うっていうのはどれくらい可能性があるのかな、っていう点は気になるところです。 picoruby.wasm のリリースビルドは 、未圧縮で1MB強くらいと言っていたと思います(最新情報は別途調べてほしい )。(追記f: mruby vm はpresym を抜いて限界までmrbgemを抜くと 700KBくらいまで減らせたかなたしか) 現実的に動くレベルにはあると思いますが、jsはブラウザがVMを起動しているのに対して、Rubyはアプリケーションコードとして VM 自体を起動するので、やはり性能面では大きなハンデを背負ってはいると思います。ReactDOM で 120KBくらい、preactやsolid.jsは10KB未満な世界観なことを考えると、その上にRubyで書かれたライブラリとアプリケーションが乗るわけだから、Rubyで書ける代償は小さくはない気はします。 ここは三日目のMatz氏のキーノートにもつながってくる議論で、VM はまだでかい。WASMにするなら、MatzのSpinelとか、あとDragonRuby社の lightstorm みたいな、AOT で WASM にコンパイルする方向の可能性ってどうなのかなーというのが気になるところ。AOT セーフなRuby である代わりに 直接WASMにコンパイルされて高速になったら普通に世の中で使われる余地があるような。 あと気になったのは、プリエンティブスケジューラを持っている、ていうところです。ブラウザのイベントループでyieldするのが自然なような。 そこについて質問しそびれました。 #### [Rapid Start: Faster Internet Connections, with Ruby's Help](https://rubykaigi.org/2026/presentations/kazuho.html) 同じ時間の Ruby in the 8-bit world も観に行きたかったんですが、微妙にネットワーク関連の話も関心があったのでこっちに居ました。 この直前が自分の発表だったので、半分聞いてなかった。輻輳制御アルゴリズムの話あとで見返したい。 記憶に残っているのは、Rubyくらい短い記法の言語で jq みたいなものが書けて、それがJITで十分に高速化されると価値がある、みたいな話です。たしかに。そうかも？　この主張は、RubyKaigi で Rubyたいして関係ない話をする上でのリップサービスも多少あったかもしれないけど、その視点は新鮮でした。ワンライナーとか書きやすいしね。 #### [The design and implementation of ZJIT & the next five years](https://rubykaigi.org/2026/presentations/tekknolagi.html) 全編を通して一番興味を惹かれた発表だったかもしれません。 Ruby の文法でも 、いやむしろRubyの文法だからこそ JITの価値が発揮される、という視点がなかったので、言語化がむずかしいですが、視野が広がりました。 これとJRuby の発表と合わせて、MRubyCS も C# IL をダイレクトに吐かせればええやん、と思った。(が、Unity使うなら利便性が若干微妙なので迷うところ) 先に書いたZJITのコンセプトがけっこうこの発表で語られてました。next five yearsー #### [PicoRuby as a Multi-VM Operating System](https://rubykaigi.org/2026/presentations/kishima.html) mrubyで動くマイコン用のOS。 - [Family mruby OSーFreeRTOSベースのmicroRubyマルチVM構想](https://blog.silentworlds.info/family-mruby-os-freertosbesunomicrorubymarutivmgou-xiang/) - [Family mruby Narya 基板 (v3 prod r1) - Kishima Craft Works - BOOTH](https://silentworlds.booth.pm/items/8128031) > マイコン単体でmrubyの開発、実行が可能な開発プラットフォームです。オーディオ・グラフィックス機能を備え、ESP32で動作するように設計されています。 ハードウェア基盤づくりも含めて、アプリごとにmruby VM を立ち上げるカーネル基盤、 映像、音のmrubyからの制御、その上のウインドウシステム、そしてその上で動く ファイラーや Flappy Bird みたいなやつとか Doomみたいなやつ、なにからなにまですべてを自作していた。すげえ。 マイコンの知識がまったくないので、詳細をあんまり理解できていないかもしれませんが、会場でデモ映像と音が出た瞬間、なんというか、普通のPCから出力されるそれとはなにかが違う念のようなものが発せられているのを感じた。 コンピュータでなにかをつくること自体への純粋な情熱を感じます。もはや狂気。自分にはほとんどまったくないものかもしれない。役に立つとか売れるとか評価されるとか誰かと比べるとか、最初からそういう地点にいない活動には畏敬の念を感じます。 これを観て、ああおれもデモやればよかった。と思いました。 #### [Lightning Talks](https://rubykaigi.org/2026/presentations/lt/) この日一番会場が湧いていたのがLTだった気がします。 時間が短いことによって、高速なリズムが生まれていてどんどん人々のテンションが上がっていってました。 やっぱり、技術系のトークといえど、聴衆がいる以上は、ライブ感というか、話し手と聴き手の互いの波がかみ合うと伝わるものが違うですね。 Road to RubyKaigiの歩くやつおもしろかったです。 これを観て、ああおれもデモやればよかったわ。と思いました。 ### Day2 TODO: #### [Twenty Years of JRuby](https://rubykaigi.org/2026/presentations/headius.html) 以前から、僕のMRubyCSのredditのスレをなぜ JVMの話で荒らしてくる人がいて、いったい何者なんだ…と思っていたんですが、その正体は、RubyKaigi 2026 Day 2のキーノートを担当する JRuby Guy氏でした。 JRubyのことをあまり知らなかったんですが、僕も一応は C# で Ruby処理系に取り組んでいることもあり、勉強になる部分が多かった。 - JRuby には JIT がある。Ruby ASTから JVM のバイトコードにJIT コンパイルしているとのこと。ああこれって普通にできるんだ。というの知れてよかった。 - JVM のバイトコードに dynamic invoke というものがあって、まさにJVMの上でRubyのような動的言語を動かすためのもの(?) らしい - あと、Array/Hash とかの 型特殊化された実装を用意しておく、みたいなのは MRubyCS の最適化にも使えそう。その辺とかも参考になった。 - JRuby は GIL がない、というのを知らなかった。だからJRuby の Thread は CRubyの Ractorより普通にコアを使い切れる。そりゃそうだ。てか 、GILがあったとしてもべつにレースコンディションが防げるわけじゃないんだからこれでよくない? - JVM 自体の性能にも触れられていてよかった。JVM はやっぱ偉大ですね。(NET (C#) も匹敵するくらいすごいよー) 改めてJRubyについて調べてみると、Ruby AST → 独自のIR表現 → JVM バイトコード or そのまま実行 、というパイプラインを持っているらしい。 JITありなし両方できるこの構成は、mruby on C# を考える上でも理想的だと思いました。 - IR表現をそのまま実行できれば、ホットリロードは維持できる & AOT環境でも動作する - IR表現を元に最適化を施せれば、JIT コンパイルできなかったとしても価値がある - JIT すれば バイトコードマシンの限界の速度を越えられる (ただし環境は選ぶ) 英語が半分くらいしか聴きとれてないので後で動画を見直したいっ。 英語 → 日本語の通訳はサポートしてくれないのかな。みんな英語聴きとれてんの？ #### [The AST Galaxy to the Virtual Machine Blues](https://rubykaigi.org/2026/presentations/ko1.html) Partial Evaluation という言葉を知らなかった。Rubyでも部分評価して高速な実装を吐ける、というところ、なんか応用できないかな? という視点で聴いていた。 これも英語だったし、部分的にしか理解できてないので動画出たら見返したい。 #### [Uzumibi: Reinventing mruby for the Edges](https://rubykaigi.org/2026/presentations/udzura.html) オルタナティブmruby VM 実装している仲間として 聴きに行きました。 mruby/edge は Rust 製の mruby vm実装。WASM ターゲット特化らしいですが、そういえばどの辺で実装が WASM意識されてるのかはよくわからなかったかも。 [mrubyedge/uzumibi](https://github.com/mrubyedge/uzumibi) は、mruby/edge VM をつかったWebサーバをCloudFlare Workersにデプロイできたり、DurableObject や Queue が利用できるとのこと。デモもありました。サーバレスで実用的に使えるようなれば便利そうですね。 VM 実装の互換性とかパフォーマンスについては僕のMRubyCSのほうがかなーり先行してる、と思うんですが、「エッジで動く」という用途がRuby勢の心を掴んでおり、こちらの発表のほうが注目されてたかなあ。 picoruby.wasm とかもあるけどどっちがええの、というのは気になるところです。mruby/edge のほうがだいぶ軽いみたいです。現状は、リクエスト毎にVM起動するから 割り切って GC もない、と言ってました。思い切ってるな。 rubyのWASM化については、picoruby.wasm と同じで、VMをデプロイするよりも AOT型のほうが可能性あったりなかったりしないのかな、ていうのが気になるところなんですけど、質問しそびれました。まあでも、ゲーム開発とおなじで、開発環境ではホットリロードできるべきか。 mruby が C マクロだらけ で書かれているが故の FFIしずらさ、みたいなのがあるので、mrubyの Rust実装があることは歓迎したいところですね。そういえばせっかくなのでFFIビリティも高めてくれたらゲーム制作勢も使いやすいかもしれない。ただ、現状のmruby/edge が成熟しているかというと、これからな部分はけっこうありそうDESITA。 この発表を見て、ああおれもデモをやるべきだった、と思いました。 #### [Surviving Black Friday: 329 billion requests with Falcon!](https://rubykaigi.org/2026/presentations/ioquatix.html) Fiber + FiberScheduler によるウェッブサーバー実装「Falcon」のプロダクション利用事例。 Ruby界隈は ノンブロッキングI/O に興味ないんじゃないかと勝手に思ってましたが、立ち見がでるくらいの人気セッションでした。329 billion rquests という数字に吸い寄せられて人が集まっていたのかな。 FiberShceudler は C拡張内でやっている I/O に対しては無力である、など、Shopifyが嵌ったFiberアンセーフなコードの問題などが赤裸々に語られていました。エコシステムが未完みたいですね。発表者のSamuel氏は、Async gem や Falconの作者らしい。 件の事例では、たしかスループット改善幅が 10-20% くらいだと言っていたと思いますが、本来はもっといけるんじゃ? gRPC のC拡張が I/O でブロックする、というお話でしたが、これはDB が Spanner であるために DB接続プロトコルが gRPC になっている、ということだと思います。 通常の ActiveRecord + PostgreSQL みたいな構成の場合はどうなるのか、というところも普通に気になりますが、今適当に調べた限りでは、完全にはノンブロッキングI/Oになるのはまだ、という状況らしいです(違ってたらすいません) Async gem は Linux では io_uring を使っていたりとか良い感じっぽいので、今後のエコシステム充実に期待したい。 FiberSheduler自体はランタイムのコアに入っているが、 実装は外部依存、という構造は、Rustのasyncを彷彿とさせます。RustはRustで、けっきょくtokioのAPI に依存せざるをえなかったりとかの光景が繰り広げがちな気がしますが、Ruby は Async gem 以外の実装がなさそうなのでそういう意味では一本化はできてる、のかな。 FiberScheduler による Asyncエコシステムは、Rubyライブラリ側の対応を必要としないので、今回紹介されていた問題の改善が進んで普及したら Rubyサーバーの用途がもっと広がるんじゃないかな、と思います。 #### [A Faster FFI - RubyKaigi 2026](https://rubykaigi.org/2026/presentations/tenderlove.html) 話の展開がわかりやすい上に、技術的にもかなりおもしろかった。 FFI でのオーバヘッドって普段意識してなかったんですが、Rubyのスタックはネイティブのそれとデータ表現が違い過ぎるため、読み替えと積み直しに余計のオーバヘッドがかかるということっぽい。そこを踏み込んでいくのはかなり難しい課題に思えました。Rubyの最適化は動的ならではの課題があったりしますが、知らなかった領域の話が出てくるので、Ruby処理系あんまり関係なく勉強になるっす ### Day3 TODO: #### [Matz Keynote](https://rubykaigi.org/2026/presentations/yukihiro_matz.html) Ruby ASTから C にコンパイルすることで高速 AOTコンパイルできる。 そんなことできるんだ……そこの印象が強い。 「mruby VM でもまだでかい」 という話のなかで、「C#とかRustでmruby実装している人がいたり〜」と、一言だけ僕の発表にも触れてくれてたのが記憶に残ってます。 [matzh/spinel](https://github.com/matz/spinel) は、手でコードを書かずにぜんぶAI に命令して数ヶ月でこしらえた、と言ってました。そうなんだ。 「Ruby をASTから C# IL にAOTコンパイルするやつつくっといて〜」とAI に言ったら似たようなのできそうです。(既に、JVM バイトコードにコンパイルすやつをつくってる人をみかけた) ということは、同じアイデアを思いついて取り組みさえすれば、誰でもできた可能性があった、ということですね。 Ruby AST から AOTコンパイルできる、これができるという発想を持ってなかったわ。WASM にビルドしたい時に、「VMでかい」という課題感は感じていたけど、やりきる方法論もなかったっすわ。 同じエーアイが使えてもアイデアとか対象への理解の深さがないとやっぱだめっすわ。 ## 得られたもの RubyKaigi 2026を振り返ると、全体的に、Rubyという動的すぎる文法に対して、さまざまなアプローチでのコンパイラパイプラインによる最適化手法が登場していて、難易度はともかくそれが現実に存在する、ということを知ったことで、考え方の幅が広がった。 - JRuby : AST → 独自IR → JVM バイトコード - Spinel: AST → C - ZJIT: YARV → SSA HIR → LIR 自分の C# 製 mruby の取り組みにも応用できそう。AI もあるしよお。 近年は、C#/Unity界隈周辺でしか知らなかったので、別の視点やモチベーションをもっている人々の活動にふれられて、自分のなかの空気がすこし入れ替わったかんじがしました。 MRubyCS の最適化や改善のアイデアがいろいろ得られたのはよかったです。 いろいろな人の活動を見てると、まだまだわっしもライブラリ開発とか、技術へのコミットがぬるいなー とおもった。 ## 謝辞 発表する機会あざました。同時通訳もしていただけ、運営してくれてる方々には感謝です。 誰もかまってくれなくて暇だったので、けっこう適当にいろいろな人に話しかけてしまいました。相手してくれた方々あざました。 今回、プロポーザル送ってみたのは、omotesando.rb の人々が勧めてくれたからでした。どうもありがとう。 謝謝。 ## 今月の進捗 MRubyCS についえはやることが山積みなのでちょっととりかかってます。(とりあえずAI にやらせられる範囲で)。 あとは、やっぱりMRubyCSていう名前変えたいかもしれない。1.0 にするときに名前変えたいなー。「〇〇Ruby」 と名付けたほうがいいのかな。「ChibiRuby」とかは空いてる。あとはいっそ「HadashiRuby」 とか……。うーん、でもやっぱ C# かつ mruby っていうことは素直に伝わるようにはしておきたいかもしれない。 発表でも触れましたが、自作mruby VM をつかいまくってる #ぶたのゲーム がもうすぐできそう。5月(来月?)はなんらか 発表できるといいなあ