RubyKaigi 2024二日目（16th, May）に登壇します。
本ブログで前々から言っている mruby/edge に関する発表です。
構想自体ははっきり言って去年のRubyKaigi CfPオープンぐらいからあって、地道な素振りをしていた。懐かしい。
発表は英語で行うらしい。日本語で事前情報がある方が頭に入りやすい方も多いかと思うので、メモがてら話そうとしていることを残しておく。無論当日までに変わる可能性もある*1。
世は大WASM時代を迎える----
これは言いたかっただけだが、実際WebAssembly(WASM)は世界に注目されるアイティー技術の一つとなっている。
個人的にはブラウザで動かす側面とともに、サーバサイドだったり、envoyやfluent-bitなどへのWASM組み込みだったり、あとyoukiみたいなやつを使ったコンテナとしての動作とかに興味がある。
そういう側面に注目すると、WASIへの対応ももちろんだが、そもそもWASMの関数のimport/exportが手軽に設定できると嬉しいなという気持ちがmruby/edgeの大きなモチベの一つになっている。
mruby/edgeはこういうコードを書けば:
# plus.rb # @rbs plus: (Integer) -> Integer def plus(arg) arg + 2000 end
plus() という「関数」をWebAssembly経由で呼び出せるようになっている。
WebAssembly.instantiateStreaming(fetch("./plus.wasm"), importObject).then( (obj) => { console.log("plus(24) = ", obj.instance.exports.plus(24)); }, );
丸っとRubyを動かすのではなく、WebAssemblyのいちパーツとして動かせるものを生成したい（その結果バイナリサイズも減って欲しい）、というのが設計思想のコアになっているんだと思う（こういうの欲しいな、と無意識で作った結果ではある）。
正直この辺の深掘りのためにはComponent Modelとかが重要そうだが、何もわからないのでkateinoigakukunさんの発表は真剣に聞いて勉強しなきゃって思う。ヒントに満ちてそうな気もする。結果その後の数時間でスライドが更新される可能性もある...。
RBSも使ってみました
上記の Kernel#plus をWASMバイナリでexportさせるには、以下のようなRBSファイルを plus.export.rb と名付けて用意する。これを mec というコンパイラが認識して plus: (i32) -> i32 をexportする。
def plus: (Integer) -> Integer
なお呼ぶだけのエンドポイントなら --fnname というオプションでも対応できるが、型指定ができない。
importについても同じく plus.import.rb を用意してRBSを書けばOK。Rubyスクリプトに実装を書く必要はない（外からの関数なので）。Rubyのスクリプト内部では普通に呼べばOK。
こういう感じでRBSをインタフェースの型記述のために使っている（いや、RBSは型記述言語か？）のはあんまり想定していない使い方な気がしていて、この辺の意見とかはちょっと知りたい。
また、こういうことをしているのでsoutaroさんの発表ももちろん聞きたい、のだが、kateiさんの真裏なんですよね...。
mrubyの話もするはず
まず、WASMを手軽に使いたいのがモチベみたいな話をさっきしたが、すまん、あれは嘘だ。本当はVMを自作したかっただけなんだ。そのターゲットとしてmrubyの命令互換VMを作りました（ます）。
mrubyのVMは個人的にはとてもカッチョいーので好きだ。命令セットを眺めるたびにこれで何かしたいと思っていた。
というより「何かした」のが2021年に話したRucyなのだ。
Rucyの時は、mrubyのバイトコードをそのままeBPFのバイトコードに翻訳して、成果物としてLinux内部のeBPF VMで動かせるようなバイナリを生成した。
mruby/edge では、WASMはeBPF VMよりもうちょっと制限が緩いためこのアプローチはしておらず、mrubyのバイトコードとそれを動かすためのVM実装をひとまとめにして、結果的に「ワン・WASMバイナリ」とも言えるものを作って動作するものを生成している。
そのVM実装の制約をなるべくなくすために、今回RustでVMをスクラッチ実装している。したがってWASMへのコンパイラもrustcになっている。みたいな話がされるだろう。
そう言いながら現時点ではmruby互換のVMとしての実装があまり進んでいないので、正直この辺はちょっと深く話せないかも。mruby(/c)とかの実装は参考にしてるけど、Rustなので、あ、そうだよね... 所有権がライフタイムでADTだよね... ってことは多いのだが...。 Vec::leak() !!
むしろKaigi期間に実装を進めるんだと思う。来週の自分頼むよ。
前提知識が多い...。
上記を踏まえると、私のトークのジャンルは以下の通りの情報過多になる。
わかっているんだけど、これらの知識は「普通にRailsでお仕事をしているRubyist」が持っていることを期待できない内容だと思う。そもそもRubyの開発自体の話が多いので前提知識を期待していない話者は多いと思うけど、私のトークの場合「Rubyのコア開発」近辺のトピックとも外れており、要するに周辺分野で、サブカル発表なのだ。 というか毎年そういうトークばっかりしているのであんまり反応や感想をもらえない。ただまあ、もちろん私の関心分野に近い聴衆の方とお話しできる機会ももちろんあるし、そういう時は大抵技術的にザクっと刺されたりはしてます。
なんかそんな感じなんですが、「def fib... って書いたらそれがブラウザで動くやで、すごくね？」という自慢話をしていい貴重な場所らしい（誤解あり）ので、胸を借りるつもりでおしゃべりします。
こんなサブカルおじさんの英語でのトーク、5/16の 14:50 ~ からあるそうです。
何の役に立つの？
なんの役に立つんだ... 上の「勢」情報で一つでも琴線にかかればあるいは。
ただ、WASMはマジで「来る」と思うので、WASMの基本的なところで引っかかりましたみたいな私の発表が役に立つ場面もあるかもしれない。
発表の推薦図書
発表を聞く際の推薦図書は1冊あって（今更言っても読めないかもなのだが）:
WASMモジュールの仕様とか、なるべく抽象化を挟まないブラウザでの使い方を解説しているのでおすすめ。C++とJavaScriptを雰囲気でも読めた方がいい。
あとmrubyについては近藤さんという人が本を出していて、この3章あたりで、WASMでないmrubyがどういう感じでワンバイナリしてるかみたいな説明があった気がする。mruby/edge+mecもこの設計を踏襲しているので理解の助けになりそう。
... みたいなメモを書いていたらなんのための文章かわからなくなってきたが... 言いたいことは:
RubyKaigiではとにかく人と話したい、感想が欲しい
あとできれば承認されたいが、むべなるかな。5000兆円も欲しい。
承認していただかなくて問題ないので、ただできれば技術的な議論やアイデアの提案、要望*2、間違いの指摘などを当地でいただきたい。他の話でもOK。
パソカタしてても絶対に即レスするので絡んでください。
