見出し画像

RubyKaigi、悔しさと情熱とあの夏

Uchio Kondo

免責事項: この文章について

この文章は元々、RubyKaigi 2024の参加直後に執筆した振り返りの文章です。

ただ、書いていてなんか色々… 恥ずかしいなってなって、公開していなくて、すっかり忘れていたのですが、まあ今公開してもそんな誰も読まないかな、将来の自分ぐらいだなと思ったので、ほぼ修正なく公開します。

本当は福岡Rubyist会議04の宣伝も含んでいましたが、流石にそれは削除しました。

RubyKaigi 2024 で登壇してきた。

このnoteには私の過去やクソデカ感情を時系列でまとめたりします。技術的な話題と情緒的な話題をあえてないまぜにします。udzura個人に興味津々の人だけ読んでください！

私とRubyKaigiと私

最初に参加したRubyKaigiの記憶は曖昧だが（なんか、つくばだったような…）ひとまずはRubyKaigiが生まれ直して、そのシーズンに最初に登壇してからのことを思い出す。

最初は京都。

Haconiwaという、mrubyとC言語でいわゆるLinuxコンテナの実装をスクラッチで書いて動かしたのでその話をした。ただ、これはOCI等の標準に合わせて作っていなくて（やってもよかったけど、標準に合わせて実装をするのは大変で、youkiさんまじパネエっすって思う）、今は開発していない。

広島は落ちたのと、子供が小さかったりしたのでスキップした。

仙台でも話した。この回は、あまりこれといった尖った話はできなかった記憶…。

その次は福岡だったのでオーガナイザーを手伝ったりした。この回はオーガナイザーをしながらしゃべった。当時、仕事の一環でCRIUという技術を検証していたのと、上のHaconiwaと組み合わせて動かしてたのでその絡みの話をした。
CRIUは実は今でもそこそこ興味あるんですけど、もはや追いきれない…。

福岡で燃え尽きてたらコロナ禍が来た。が、そもそもこの年は家庭の事情があり、（takeout含め）プロポーザルを出していない

その翌年もtakeoutで、Rucyという、RubyのスクリプトをeBPFにコンパイル（文字通りなので資料を見てほしい）するものの試作品の話をした。
Rucyは個人的にはめちゃくちゃ面白いテーマなのでもう一旗挙げたいのだが、設計思想を見直してLLVM-IRを吐かせた方がいいよなってなって、そしてLLVMに関する技術は世の中でも難しいものの一つだよなーと思っていつかやろうと思って止まってますね…。

次の年は久しぶりのオンサイト開催で、この年は拙作したRbBCCというeBPFを使うためのgemの話をした。話せば長くなるが、eBPFのツール開発はBCC系統の、いわゆるJITでBPFバイナリを生成するSDKではなく、AOTでBPFバイナリを作ってCO-REという技術によりカーネル間の差分を吸収する（一種のリロケーションを行う）方式が主流になりつつある。したがって名前通りBCC系統であるこのツールでさらに一旗という気持ちは今はあんまなかったりする。Rucyを頑張った方がいい。
ただ、もちろん簡単なツールや学習用途ならRbBCC+libbccは普通に使えるので細々保守したいとは思う。

さて、次の年には転職をして仕事でRubyに関わらなくなった。時間を捻出してアイデアだけ（pure Rustでtls周りのことをするgemを作ってCRubyに組み込めばOpenSSLの依存外せるくね？って提案した）出した。おそらく実装がないので落ちた。いや、このアイデアは今でも試しに作ってみたいんだけどね…。

ということで今年は久しぶりに参加できた。

何の話をしたかというと、WebAssemblyのバイナリ（WASM）をRubyスクリプトから作ろうという話をした。それも、import/export周りをサポートしたようなものが欲しいなと思っていた。

そこでmrubyを用いて、Rubyスクリプトをバイトコード化し、さらにそのバイトコードを実行可能なVMをセットにして固めればいけるんじゃね？　と思って実際そう作ったものの話をした。それがmruby/edge。

アイデア自体は、そもそもmrubyとしてはこういう（バイトコードを実行環境と固める）のは普通の使い方なので、例年のように奇抜な（？）ことはしていない。ただ、今回の面白ポイントは mruby bytecode 互換のVMを再実装し始めていることで、これはWASMについて調べていくと、あれ、これはあんまりmruby自体に依存しすぎても対応が大変なんでは… と直感したのと、VMを再実装したかったからというのが大きい。VMを再実装したかった。

その結果パフォーマンスチューニングが本気で間に合わず、でも測らない・公表しないのは不誠実だよなって思って測って、結果80倍程度遅いという話をして注目を集めてしまった。

普通に反省すべきところとしては、チューニングってやはり普通に機能が揃ってからだよなというのはあり、VMとしての機能が揃ってない段階での計測にそもそも意味があるんか？　というのは向き合いたい。でも、大きな場で、評価・計測がない発表というものをしたくなかったんだよな…。

技術的サブカル野郎の苦悩

砕けた（さらに言えばふざけた）文章なのと、男性である俺の話しかしていないので「野郎」という表現を使います。

で、ここまでのRubyKaigi登壇記録をまとめると、軸はLinuxコンテナ（自作勢）、CRIU、eBPF、という感じで、とにかくシステムの低いことをやりたがっている（そもわりに本当に低いところはできない…）感じがする。あと、ニッチな技術でまずそのテーマの説明を長い時間しないといけないみたいな。

しかもニッチといえば、mrubyの話が中心に来ることが多い。これはCRubyが嫌いということではなく（RbBCCとかはCRubyですよ！）、なんか自分のやりたいことは、ある技術やそのPoCを、コンパクトに、いろんなところにコントローラブルに適用したいみたいな方向性がある気がしていて、その用途だとmrubyはあまりに合ってしまうのでそうなりがちなだけである。ただ、WebAssemblyをやっててもまたmrubyに出会うとは思ってなかった。

（「箱庭」という名前のOSSを出したのは運命的で、あらゆるところに箱庭を作りたい気がしている。なお、箱庭という名前は、ほとんどの曲が変拍子という最強にニッチな日本のインディーバンド 箱庭の室内楽 から取っています）

今年はWebAssemblyの話をするのでメチャクチャポップじゃん！って思ってた。でも冷静に考えたらポップではありません。

ともかく、毎年ニッチな話題で登壇するので、実は会場とかで感想をもらったことが全然ないのだった…。

というか言語系のカンファレンスには普通のプログラマが多く参加する、はそれはそう。ただ、RubyKaigiなので、普通じゃないプログラマも結構な数参加するのでありがたいのはあった。

mruby/edge の今後

そういう流れで話したmruby/edgeの今後についてまずはまとめたい。

First fo Allとして、みなさんの注目を無駄に集めたパフォーマンス面だが、まず言いたいのは、ちゃんと計測して既存実装との比較を出したのでそこを褒めてくれ ！！！ ということである。

いや当たり前ですが、でも意外とやってない人も多いかなって…。

パフォーマンス面、詳しい計測や追いかけの仕方については kateinoigakukun さんから現地でいくつかアドバイスをもらって、そもそもブラウザの機能でフレームグラフが作れ、幸いというかmruby/edgeはRust製なのでデバッグ情報もしっかり入っており、まずはそれを軸にするといいのではという感じになった。

スライドに埋め込んだwasmでフレームグラフを出してみた

というかこのフレームグラフというやつは、手元で作るのはそれなりに怠いやつじゃんって思ってたけど、それがブラウザで一発なので、ブラウザって実は開発環境としていい？　という気持ちになっていた。

なのでパフォーマンスはまずは真面目にやる、でもそれよりkateiさんから「例外とか…どうするんすか？」　等のアドバイスがあり、そもそも言語機能面がちゃんと実装できるのか、設計によってはメチャクチャ遠回りするだろうし、VM実装のノウハウとかよくわからないし… みたいなとこが、あれだ、やりがいポイントだなと思った。

（そういう意味では、機能がないのでパフォーマンスの前段階なんだよな…）

正直な話、ここまでしか実装していない、パフォーマンスチューニングも時間を取れていない、という状態で当日を迎えたというのは純粋に悔しい気持ちがある。言い訳ばかりなのですが。WASMのバイナリを作る上での基本的な部分は作った状態にはしたので、takeawaysがゼロとまでは言わないが、自分的にここもやりたかった！　とか、mruby/edgeの本当の価値を伝え切れてないかも、という思いは強い。

しかし、まあ、ゆるゆるやるしかないのです…。

今年はいつもより反応が多い!!??

ただ、WebAssembly自体の話題度はやっぱり高いなって思っていて、感想まとめサイトとか経由で探すとなんかすごく色々言ってもらえて感激した。

あと、RubyKaigiにビタイチ参加していないmizchiさんから言及が飛んできて感激した。

個人的な、根拠の薄い話をする。WASMというやつ、アプリケーション組み込み技術の終着点ではないかと思っている。ブラウザでの実装も、WASMがブラウザに組み込まれただけと言える。

アプリケーション組み込み技術（アプリケーションの中に独自の箱庭を作り出す技術）の代表的なものはLua、そしてmrubyはそれを追いかけるように開発された。

しかし、WASMというやつがメチャクチャ汎用的な、それも組み込み技術で最も欲しいplatform agnosticさを強く押し出して出てきたので、これに乗っかればとりあえずOK！あとはこの庭にたくさん花を植えるだけ、みたいな気持ちになった。

しかも、Component Modelというのが鍵で、多分理解が浅いと思うのだが、コンポーネントはジグソーパズルのパーツみたいなものに将来なっていきそうで、パーツを組み合わせたらWASMのアプリケーションができるようになるよ！　と言いたいように各種資料が読めた。jcoのようなツールも触ってみたいところ。

だから、Rubyで書いたwasmコンポーネントをRustやGoのコンポーネントと組み合わせて、Pythonのアプリに組み込んで動かすぞ！　とか、その逆とか、そういう世界が徐々に近づいてる感じがある。私は文化相対主義者で、実用面はともかくいろんな言語を使いたい人間なのでそういうのは嬉しいかもしれない。

（この節、本当に間違ってたら教えてくださいね…）

Rubyコミュニティに就いて

ところで私は今、Rubyを書かないどころか、プロダクトで基本的に使っていない会社に転職して働いている。

これは文化相対主義者をこじらせたのはあるが、自分の本当にやりたい技術ってなんだっけ？　という、いわゆるミドルウェアクライシス（？？？）に陥り、一旦自分のアイデンティティとくっつきそうになっているRuby、Rubyコミュニティから距離を置こうと思ったことが大きかったように思う。振り返ると多分そう。

その結果めちゃくちゃに勉強になっているのは会社のブログでもわかって、今までの自分では作れなかったようなものをわずか2年間でガンガン出しまくっているという趣がある。特に、ミドルから下は本当に計測が大事だということ、コードを読むのも書くのもしつこくやらないとダメなこと、最後は気合いなこと、あとは気合、オウナーシップ、俺はゴールキーパーだがゴールを決めるという気持ちが大事なんだ！　等様々に学んだと思う。

とにかく成長したと思っているのだが、mruby/edgeの開発ではそういう自分の成長度合いはあまり出せてないので、ちょっとこれから頑張らないとですね...ともなった。

なんとなくまたRubyコミュニティでやることが見つかりそうな感じなので、それは良かったかなと思う。

実はRubyKaigi 2024に来る前には、「自分が今後もRubyコミュニティに関わるべきかを考える最後の機会にしよう」と思っていたのだった、だけど、行ってみると、RubyKaigi最高じゃん！ウヒョ〜　となったので、まあmruby/edgeとかその他WASM周りをうろうろしながら、来年も可能ならなんかを出しつつ、松山でブリを食べたいなって気持ちです。いい加減なものなので。

トークの話もする

完全に自分の話しかしてないので、RubyKaigiでよかったトークの話をする。

とにかくダントツでisshikiさんの発表が良かった。isshikiさんのrurubyは数年前から超注目していて、ついに！　と思っていたが現地で聞くと想像の10倍、こう…。

とにかく、市井のプログラマがとんでもない実装をするのを目撃する、という体験は人生においてあまりできるもんじゃないのに、RubyKaigiではあるので、これだからコミュニティ活動（コミュ活）やめられないよなと。資料は何度も見返したい。最高の演奏でした。

あとはめもりーさんのトークも印象に残っていて、VMを分析する内容が勉強になり資料としてもありがたかったが、tompngさんのキーノートを聞いて直前に方向性を捻じ曲げ、深い話に走ったというエピソードも良かった（なんかありがたかった）。

あとトークじゃないんだけど、yharaさんがkateiさんに突然「このLLVM-IR、僕の自作言語から生成したものだけど見てくれませんか」と話しかけて、kateiさんが「これは綺麗なIRですね〜」と評論していた場面が良かった。 #rubyfriends 。

ともかく、夏は始まったばかりだ（註: 執筆段階ではそうです）！　そして博多で夏の終わりを感じましょう（註: 執筆段階では福岡Ruby会議04の宣伝を入れていましたが、あまりにも混乱を招くので節ごと削除しました）。

夏を古くするな！

僕からは以上です。

（どうでもいいけど、40近くになっても、今でも20代前半に下北沢とか青山で見た「あの辺の界隈の」インディー音楽に縛られている。これがサブカル野郎の所以です）


この記事が気に入ったらサポートをしてみませんか？