RubyKaigiというものに行ってきました。初めて行きました。 プログラミング言語「Ruby」好きの集まる最大規模の催し、ということで、海外からの参加者もたくさんいました。 どうやら毎年、全国津々浦々さまざまな場所に開催地が置かれるとのことで、遠路はるばる同じ趣味の者どもが日常から切り離された広い空の下へ集結してしまうことによる、隔離された非日常空間、束の間のお祭り騒ぎ、ーーそんな雰囲気が自ずと醸し出されているのが独特です。 今回の開催地はなんと函館でした。東京でずっと息を止めてたけどやっとここで呼吸できたわ。と思わされるほど広い北海道の空の下、似たような人種の群れにまぎれていると、なぜか気分は音楽がまったく鳴ってないロックフェスみたいになります。 Rubyといえば日本人のMatz氏の作で、中心的な開発者は今も日本人に多い、ということで、日本人ユーザーが圧倒的に多いようです。 僕はといえば、ずいぶん昔はRubyを好んで使っていたのですが、現在では仕事ではまったく使わなくなってしまった人間の一人です。周囲にはそのような変遷を辿った人間は珍しくありません。 Rubyについて思い出すと、やはりWeb2.0 だとか 言われていた時代が嫌でも想起されます。あの頃、故TwitterとかもRuby on Rails で書かれていたし、Webサービス開発ではRubyが本当に流行っていたと思う。いや、流行っていたというより、エンタープライズ業務アプリケーションOOP界隈の「正しさ」に唾を吐き、積み重なった退屈な手段のための手段をすべて破壊するカウンターであり、ルールではなくおまえの美意識に従え、というカルチャーを花開かせた、そんな存在でした。Rails以前、Rails以降で、Webアプリケーションフレームワークの美意識はずいぶん変わったと思います。屍と化した大量の『〇〇言語で書かれたRails』が堆積した地面を僕は歩いています。 そう、あれから時代は移り変わり、あっちへ行った振り子がもう一度逆向きへ戻ってきていますが、そのことは今は忘れましょう。 あの頃は、とくに社会でなんら役に立たなそうな僕のような人間も、ぺぺぺっとWebサービスをつくつくっていれば、社会的になにか意義のあることをやっている、そんな気分になれる幻覚をみんなで見ていました。Webサービスのありかたをデザインすることは、とっても哲学的な思想の社会実装である、と、信じられていました。(まじです) 。そのような気概は持ちながらも、「そんなご大層な仕事じゃないと思うけどな…」と頭のどこかで思ってた。いまでもたぶん、みんな幻覚を見ているのかもしれませんり早く夢から冷めないと。 Rubyの不思議のひとつは、いったいどんな匂いを嗅ぎつけたのか、コンピューターに興味があるというより、非常に文才がある人間を惹きつけたことだと思います。詩想のある文章や漫画でRubyについて語っていた人たちが現れては消えていった。まじであいつらすごすぎる……あれはなんだったのか。今だにわかりません。彼らは一体、どこへ行ってしまったんでしょう。 振り返ると、現在のユーザーと比較しても劣らない程度には、当時の僕はRubyが好きだった方かもしれません。 ## 最近はRuby使わなくなった ではなぜ使わなくなったのか。理由は僕にとっては明確です。普通のアプリケーション開発の現場を主戦場としていて、時代の変遷を辿っていっている人々にとっては、たぶんあえて言うまでもないことだと思います。 - サーバサイドプログラミングの文脈 - 非同期 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.xあたりで万を持して「Concurrency」の機能が入ったと言っているが、Ractor が解決しているのは「Concurrency」というよりは「Parallelism」のほう。(性能面での意義はGILが外せること以外にはないという意味で） - RactorをConcurrencyと言ったり、Fiber を軽量スレッドと言ったりするのは、課題設定がちぐはぐ。おそらく一般のRuby ユーザーも大して理解していなくて、Ractorを使うとEarlangのActorやGoのgoroutineのようなスループットがでると勘違いしているんじゃないだろうか。 - 現在、Webサービス界隈で使われている大抵の言語はこの課題に取り組んでいる。 - この問題と対峙しているRubyコア機能として、 FiberとFiberScheduler がある。 - Webサービスのクライアントがクロスプラットフォーム化したり複雑化してワークロード分散する、みたいになるにつれ、鯖/蔵の間でデータモデルをどう共有するか、という問題が出てくる - 型定義を一次情報とした強力なコードファーストアプローチが理想系のひとつ。すくなくとも、 あとからテストを書く、あとからvalidationする、という手法よりも、「実装」を一次情報として、実装からスキーマを解決するほうが遥かに優れていると言える。 - Ruby on Railsは 「設定より規約」なので、アプリケーションの実装をコードファーストなスキーマ宣言とするようなソリューションが生まれずらい。 - Webサービスが複雑化するにつれ、Web API というものを RESTfulにつくる意義が失われた - 昔のWeb APIは「HTTPクライアントさえあれば誰でも使える」という思想があったからこそ、アプリケーションプロトコルをHTTPの仕様に後退させることに意義があった。 - 現在は、オープンなAPI とかも言語別のSDKやライブラリ経由で使うので、 RESTである意味がそんなにない。 - 複雑なアプリケーションでは、CRUD以外の動詞が柔軟に使えるほうがよい - RubyもRailsも、もともとRPC的な手法に関心がない - クライアントサイドプログラミングの文脈 - js とか C# とか Rust とか Kotlin とか Swift とかDartとか、クライアントサイドアプリケーション開発をターゲットとしている言語は、シングルスレッド非同期プログラミングのためのモデルを持っている。Rubyはそういうないし、この用途には広がりずらい。 - 開発体験の文脈 - Webサービス開発というものはある時期までは、決まったことを短い記法で書ける「スクリプト」であることが最高の生産性をもたらしていたのは本当だったかもしれない。つくるものや扱うデータモデルや求められる体験が複雑になっていくにつれて、そうではなくなった。 - 複雑で大規模なコードベースの中を、依存ライブラリも含めて完璧に高速で解析できるか、できないか、で、生産性と技術への学習効率が違ってくる。 - Rubyは字面のよさを最高の優先度に置いてるので、ここがかなり苦手 Ruby をよく使っている人と話すと、こうした課題はほとんど感じていないらしく、その辺は不思議に思っています。 ちなみに僕は、「型アノテーション」とか「async/await構文」とかをRubyに入れるべきだとはまったく思いません。 ## RubyKaigi参加と登壇の目的 「Ruby使ってない」とか言いつつ、最近はゲーム開発の文脈で mruby をスクリプト言語として使う取り組みをしてます。今のところの主目的は個人制作です。 アプリケーション開発ではRubyが主役になることはなくなったものの、DSLみたいなもののレイヤーに使うにはかなり良い、というか、本来はそういった分野で光る言語ではあると思うんですよね。 アプリケーションへの組み込みというと lua の名前がよく出てきますが、僕としてはこの分野でもmrubyが使われてもええんちゃう？ と思います。ところが、mrubyを使ってみると躓く点は多くて、ゲーム制作界隈でも「mruby撤退してluaにするわ」という発言をしている者どもを複数名観測してます。 そんなmrubyをC#環境で使いやすくするため、mruby vm をC#で再実装する、というのが最近の僕の取り組みです。 Unityとか他のゲームエンジンとの統合を簡単にすることに特化したC#製mruby実装をつくってます。 - [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#よりはるかに優れたものが出てきたら、とくにこだわらず去るC#ユーザーは多い気がします。ドライな関係です。AppleのSwiftがもっといろいろな環境のまともなIDEでサポートされて、クロスプラットフォームゲ開発で使えたら、C#じゃなくてSwiftを使いたいよ。おれ。JVMのビルドパイプラインとライブラリ群が10倍洗練されて、パフォーマンスにもっと注力されていたらC#じゃなくてKotlinを使ってたかもしれないよ。おれ。 一方、Rubyユーザーの場合、Rubyが好き、という雰囲気があります。 自分の感覚では、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ユーザーはけっこうコミュニケーションを取りやすいらしく、距離感が近いみたいです。RubyKaigi常連の者たちは、見に行くセッションを発表者の名前で選んでたらしいです。 僕は界隈の人物のことを知らないので、タイトルとかDescriptionだけ観て行き先を選んでいましたが、有名日本人コミッターの方々の発表はけっこう見逃しがちだったかも。 Rubyの最新機能についても、その機能への興味というより、Rubyの直しっぷりをドキュメンタリーとして体感できるような発表が人気だったっぽい。 ### Shopify勢の存在 みんな「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を彷彿させるで。 ある時期、Rubyに追加されていく機能とかをウォッチしていると「これ本当にRubyでアプリケーション開発してる人がデザインしてるの…？」ていう疑問を持つことがあったんですが、Shopify勢の取り組みを見ていたら、その認識は改められました。 僕はRubyが用途に合わなくなったり性能問題にぶつかると「けっ」と捨てゼリフを吐いて使わなくなったわけすが、ShopifyはRubyに留まるという選択をし、Rubyを直す、という道を行っている。その取り組みのレベルは非常に高いです。ここまでやれば、直せるんだ……、そう思うと、函館の冷凍のカニで頭を殴られたかのような衝撃を受けました。 ただの利用者が技術者面していることが多い昨今ですが、自分の道具を深く使いこみ、高いレベルで複合的な改善ができるアイデアを持ち続けられる人が技術者だと常々思います。自分もそうありたいものです……。 #### ZJIT 一般に、JIT が「速い」とされている理由は、マシン語に変換されるから、というのは半分に過ぎず、もう半分は、実行時にしかわからない情報によって最適化できるから、という側面がある。 ZJITは、Rubyバイトコードをまず SSA IR 高レベル中間表現にし、そこからloweringして SSA IR 低レベル中間表現 → マシン語、というパイプラインを通るといいます。.NET じゃん。JVMじゃん。 それ以前のYJITは、Rubyをマシン語にするというゴールを達成しているのは偉業ですが、最適化についてはのびしろがそこまでなく、型特殊化とかはあるけど積極的なインライニングとかはない模様。 Rubyという言語において、もしも実行時にしかわからない情報による最適化ができるなら、のびしろだらけです。 たとえばRubyでは、 2つの数値のうち大きいほうを返す関数を、 `[111, 222].max` とか書くことは日常茶飯事です。ここまで簡単な例だと静的解析できそうですが、実際、mrubyコンパイラだとこのコードはArrayをアロケーションしてメソッド呼び出しするコードを吐きます。 もし、エスケープ解析、Object stack allocation のような最適化が進めば、上記のようなコードもただの三項演算子と同等のコードにコンパイルできるはず。多段的なインライニングなどが進むと、もっと複雑な例も、AOTコンパイル言語とかに匹敵するくらい速くなる可能性がありそうです。 V8とおなじで、VM空間のすべての値は概念上はboxingされているはずで、boxingされた値を扱う境界では 最速にはなりえないような気がしますが、Rubyくらい短くて人間が手書きする用途に特化した文法を維持したまま、いけるところまでいく最適化が入ると、その振れ幅でインパクトはありそうです。js とかよりワンライナーとか書きやすいしよ。 ZJITは、型アノテーションを絶対に入れないRubyにとって、型の利点のひとつである最適化しやすさを、実行時解析によって突破する可能性を示しているとも言えます。 やはりRubyには、型アノテーションを絶対に入れないまま、独自路線で戦っていく背中を見せてほしいですね。 実行時の型特殊化やエスケープ解析は僕のMRubyCS でもやってみたいわー、やろっかなーと思いました。 #### FiberScheduler Ruby界隈は、型アノテーションだけでなく、async/awaitのようないわゆる「function coloring problem」に拒絶反応を示しています。 たぶんそれもあってなのか、シンタックスだけでなくついでに非同期プログラミングそのものを拒否している節がこれまでありました。 ここがなんとかなる試みが FiberScheduler です。 FiberSchedulerがすごいのは、既存のRubyのソースコードに変更を加えず、さらに言えば、既存のライブラリのAPIにも変更を加えず、I/Oをノンブロッキング化するところです。 路線としてはJava の Virtual Thread (Project Loom) に割と似てます。 Rubyでこの縛りを化した状態でバランスをとる現実的な落とし処をみつけたアイデアは非常に優れていると感じました。 考えてみれば仕組みは単純です。RubyのFiberは、コールスタックの奥深くの、ごく普通のシグネチャのメソッドからも `Fiber.yield` でサスペンドできるため、I/O する低レベルAPI に Fiber.yieldを挿入してあげれば、スレッドをブロックせずに中断→再開が一応コントロールできます。FiberSchedulerが設定されている場合、yieldしたあとで FiberSchedulerの実装がいつresumeするかを決める、ただそれだけです。 簡単ですが、かなり優れたバランス感覚じゃないでしょうか。もしも、「ライブラリのAPIは一切さわらずにI/Oをいますぐノンブロッキングにして〜」っていきなり言われたら「え？　無理です」と即答したくないですか？ 僕も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! (宝石の絵文字)」 「わーわーわー」 これです。やるべきだったのは。 たぶんあそこはそういう場だった。 もちろん、ふつうにランタイム実装のパフォーマンスで工夫したこととか、非同期メッセージパッシング合成チェインの設計の話とかもすごくしたかったんですが、その前に必要だったのはデモですね。デモ。 話したいことがたくさんあって、素材のまま撒き散らされており、焦点をどこに持っていくかぼんやりしていたので、そういう意味では準備不足でした。 もし次回があったらいろいろ改善したいです。 話している中で、やっぱり自分は 非同期プログラミングがまともにできることをかなり重視していて、それによって言語の用途が広がることを Ruby ユーザーにも訴えたい、という気持ち内から出てきました。この辺の話はもっとちゃんとしたかったですね。 Golangとかがクライアントサイドアプリを書く用途で使われない理由は、プリエンティブなスケジューラだけでは クライアントアプリ開発での非同期用途ですべての問題を解決できない、ていうのもあると思うんですよね。 Rubyがasync/awaitとかそっち系の構文に入れないのは全然いいと思うんですけど、なんらかの方法で 同じようなことできないと、現代のアプリケーション開発でよく使われてる言語と比較すると用途が狭いんだよね、みたいな話ももっていきたかったけど、時間が足りなくなったのでその辺のページはごっそり飛ばしてしまいました。 Web界隈でほとんど無視されている C# をもっと知ってもらうきっかけになったらいいな、と思ってはいたんですけど、Rubyの人にはそんなに伝わらなかったかな。C#というキーワードだけでも覚えてもらえてたらいいのだけど。 壇上を降りた途端、JRuby開発者 の人がめちゃめちゃ気さくに話しかけてくれたんですが、英語ができないので、 「あ、あのあのあの…えっとえっと…」となって適当な返ししかできなかったのが非常に残念でした。JVM と .NET の話とか本来はいろいろしたかった。やっぱ英語は話せるべき! ## そのほかの発表の感想 (思い出したら追記します) ### Day1 #### [The Journey of Box Building - RubyKaigi 2026](https://rubykaigi.org/2026/presentations/tagomoris.html) Rubyのモンキーパッチも含めたクラス/メソッド定義を隔離できる新機能の話。ここに Box という名前を与えるのがRubyっぽいといえばRubyっぽい。 同一プロセス内で複数アプリをーー という話もあったので、V8 の isolateとかと少し似ているかもしれないけれど、メモリ領域を隔離するというより、コード定義を隔離するものらしい。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 も実装されてるそうです。 ブラウザでRubyが動くってことで、デモで会場が湧いてました。とくに ブラウザの開発者ツール上(だったかな?) で rubyデバッガが動いているのが目を引く。これは見てるほうも「おー」ってなるし、デバッガがあることの便利さも見てわかる。 (デバッガはMRubyCS にも入れよう。と強く思いました) 実際、Rubyをこういう用途でWASMで使うっていうのはどれくらい可能性があるのかなっていうのは気になるところです。 wasm のリリースビルドは 、未圧縮で1MB強くらいと言っていたと思います(最新情報は別途調べてほしい)。現実的に動くレベルにはあると思いますが、。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) 全編を通して一番興味を惹かれた発表だったかもしれません。 先に書いた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: ### Day3 TODO: ## 得られたもの MRubyCS の最適化や改善のアイデアがいろいろ得られた。 近年は、C#/Unity界隈周辺でしかコード書いてなかったので、別の視点やモチベーションをもっている人々の活動にふれられて、自分のなかの空気がすこし入れ替わってよかった。 ## 謝辞 発表する機会あざました。同時通訳もしていただけるなど、運営してくれてる方々には感謝です。 誰もかまってくれなくて暇だったので、けっこう適当にいろいろな人に話しかけてしまいました。相手してくれた方々あざました。 ## 今月の進捗 個人の活動の進捗はほぼありません。 MRubyCS についえはやることが山積みなのでちょっととりかかってます。(とりあえずAI にやらせられる範囲で)。 あとは、やっぱりMRubyCSていう名前変えたいかもしれない。1.0 にするときに名前変えたいなー。「〇〇Ruby」 と名付けたほうがいいのかな。「ChibiRuby」とかは空いてる。あとはいっそ「HadashiRuby」 とか……。うーん、でもやっぱ C# かつ mruby っていうことは素直に伝わるようにはしておきたいかもしれない。 発表でも触れましたが、自作mruby VM をつかいまくってる #ぶたのゲーム がもうすぐできそう。5月(来月?)はなんらか 発表できるといいなあ