STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

kateinoigakukunがプログラムに興味を持ったきっかけ、Wasmとの出会い。深掘りRubyKaigi 2022 with ko1 & kateinoigakukun 文字起こしレポートvol.1

2022年10月5日に『深掘りRubyKaigi 2022 with ko1 & kateinoigakukun ~ RubyKaigiどうでした&RubyのWASI/並列どうなるの? ~』を開催しました。イベントでお話した内容を3部作でお届けします。


自己紹介

fujimura:皆様、今日はお集まりいただきありがとうございます。今日はゲストにkateinoigakukunさんと、笹田さんをお迎えしております。プログラムとしては、前半でkateiさんにWasmの話を聞いて、後半に笹田さんに並列並行のところを聞くというようなコンテンツでやっていきます。

さっそく始めていこうと思うのですが、僕らの自己紹介と、kateiさんの自己紹介から始めようかな。僕は STORES でCTOをやってる藤村と申します。RubyKaigiもリアルで参加して、非常に楽しかったです。じゃあ、hogelogさん。

hogelog:私は STORES で、バックエンドのエンジニアだったり、インフラを触ったり、いろいろその辺をやっているhogelogといいます。よろしくお願いします。RubyKaigiもいち参加者として、非常に楽しく参加させていただきました。

shyouhei:卜部といいます。ここ最近、久々にRailsを触るプロジェクトにアサインされていますが、STORES の中ではRailsに限らず、いろいろやっています。RubyKaigiも楽しく参加させていただきました。よろしくお願いします。

kateinoigakukun:僕は本業は大学生で、RubyKaigi 初日のKeynoteでお話をさせていただきました。kateinoigakukunというハンドルネームで活動しています。よろしくお願いします。

fujimura:笹田さん、おしゃべりいただいても大丈夫でしょうか。自己紹介いただけるとありがたいです。

ko1:クックパッドの笹田と申します。RubyKaigiに参加して、私も発表と企画を手伝ったりしておりました。今日は、よろしくお願いします。

fujimura:よろしくお願いします。

kateinoigakukunさんの発表「Ruby meets WebAssembly」をざっくり

fujimura:では、早速kateiさんのWasmの話に入っていこうと思うんですけど、超ざっくりどういうお話をされたかっていうのを教えていただけますか。もうある程度みなさんが知っている前提で大丈夫です。

kateinoigakukun:すごくざっくり言うと、去年から僕がRubyアソシエーションの助成金プロジェクトで行っていた、RubyをWebAssemblyにコンパイルするプロジェクトの成果発表みたいなかたちで、発表させていただきました。話の流れとしては、何でRubyを WebAssemblyにしたいかや、実際のデモだったり、移植するにあたっての技術的な詳細部分を紹介しました。

fujimura:ありがとうございます。発表してみてどうでしたか?準備が大変だったとか、こういうのは意外な反応だったなとか。

kateinoigakukun:準備はかなり大変というか(笑)これまでのRubyKaigiの発表も復習というか、研究しました。伝えたいことも言いつつ、自分の言いたいこと、自分の自慢したいこともしゃべっていいんだなみたいな、そういう空気感もわかったので、そういう感じで準備してました。

fujimura:ありがとうございます。久々のオフラインでのRubyKaigiの一発目がkateiさんのめちゃくちゃインプレッシブなトークで、みんな一気にテンションが上がったんじゃないかなと。会場の雰囲気を見ててもすごいと思いましたし、すばらしいセッションでした。ありがとうございました。

kateinoigakukun:いや、よかったです。

fujimura:で、ちょっと質問したいこと、めっちゃあるんですけど。

kateinoigakukun:(笑)

素人質問コーナー to kateiさん

fujimura:最初に素人質問コーナーとして、僕が何も知らない体でいろんなことを聞くっていうのをやろうと思います。Wasm上で動くRubyとCRubyって、何がどう違うんですか。

kateinoigakukun:基本的には、何も変わらないと思っていただいていいんじゃないかなと。まずはRubyをWebAssemblyにコンパイルするのではなくて、CRubyっていうRubyインタプリタをWebAssemblyにコンパイルするというアプローチなので、インタプリタ上で動くRubyスクリプトの動きとしては全く変わらないんですね。基本的なアイデアとしてはそうなります。ただ、いくつかWebAssemblyに起因する制約があって、そこをごにょごにょするので、そこに起因する制約はあるかもしれないという感じですね。

fujimura:ありがとうございます。もうひとつ、素人質問なんですけど、Wasmって何がうれしいんですかね?

kateinoigakukun:何でしょうね(笑)。でも、一番うれしいのは、いろんなところで同じプログラムの形式が使えるようになることかなと思っています。例えばLinuxだったら、ELFがそのフォーマットとして使われてると思うんですけど、ブラウザで動くみたいなところを超えて、プラットフォームに依存しないプログラムの形式で、ユーザーが入力としてプログラムをサービスに与えるみたいな。そういうモデルのサービスみたいなことが簡単に実現できるようになるのが、一番うれしいところなんじゃないかなと僕は思っています。

fujimura:これからわれわれが想像もしていなかったようなユースケースが、多分出てくるんでしょうね。

kateinoigakukun:そうです。僕も全然わかってないんで(笑)

Asyncify以外の選択肢はあった?

fujimura:素人質問コーナーを終えて、僕が聞いてみたかったことコーナーにいきます。Asyncifyを使って、難しい部分を処理したっていう話を見たんですけど、何かほかの選択肢ってあったんですか?

kateinoigakukun:ほかの選択肢としては、まず最初に考えていたのが、WebAssembly自体に例外機構が実は提案されていて、それを使う選択肢もありました。なんですけど、ブラウザ上のChromeだったり、Safariだったりは、大体その追加機能を実装していたので、それでいけるだろうと油断していたら、メジャーなWeb以外のランタイムのwasmtime*1っていうのがあるんですけど、それが実装していないということが途中でわかりました。それに助成金プロジェクトが始まったあとに気がついたので(笑)

fujimura:(笑)

kateinoigakukun:それでいけるだろうと踏んでいたところに、もうちょっと頑張る必要が出てきたという感じでした。なので、ほかの選択肢としてはWasmネイティブな例外があります。

fujimura:ゆくゆくはWasmネイティブな例外を使うほうがいい、よさそうみたいな感じなんですかね?

kateinoigakukun:そうですね。できるだけAsyncifyを使わないほうにいきたいですね。

サイズ削減・Asyncifyを使わずに速くするアイデア

hogelog:サイズの話がRubyKaigiのときにあったと思うんですけど、あれは削減する、こうやれば削減できるなみたいなアイデアとかあったりするんですか?

kateinoigakukun:基本的には、Rubyスクリプトをそのままvfsに埋め込んでいる現状なので、まずそこに無駄な情報がたくさんあります。例えばRubyスクリプト自体を埋め込まないとしても、例えばASTだったり、シリアライズしたもうちょっとコンパクトな形式にはできるかなと思います。一番お手軽な方法だと、JavaScriptみたいにminifyする、スペースだったり、改行だったり、そういうシンタックス的に余分な部分を削って、ファイルに落とし込むのがいいかなと思ってます。なので、いろんな選択肢はあります。

hogelog:それやると、どのぐらい効きそうですか?

kateinoigakukun:パっと試してくればよかったなと、今、絶賛思ってます(笑)

hogelog:もうひとつ聞いてみたいのが、パフォーマンスの面でも、Asyncifyでちょっと遅くなってるけども、これ改善の余地はあるって話があったかなって思うんですけど、それってどうやるんでしょう?

kateinoigakukun:まずAsyncifyをできるだけ使わない方向にしていくっていうのが、前提としてあります。ただAsyncifyを使わないといけない状況、使わないといけない機能が3つ、保守的GCと、Fiberと、あとsetjmp、longjmp、例外ですね。で、例外については、Wasmネイティブな例外機構があるので、どうにかなりそう。で、それ以外の2つ、Fiberに関してもどうにかなりそうな雰囲気があります。ただ、保守的GCに関しては、Wasm側と交渉が必要な気がしているので、そっちにアプローチしていくっていうのが、今後正当な方法なのかなと思っています。

hogelog:なるほど。Wasm側のランタイムの成熟に従って変わっていくわけですね。

kateinoigakukun:そうですね。

kateiさんとWasmの出会い

shyouhei:僕なんかすごいそういうのと全然違う話で聞きたいんですけど、まずWasmとの出会いを。どこからWasmに入ってきたのかっていうのと、Rubyとの出会いももちろん聞きたくて、RubyでWasmをやりますみたいな話って、これまでもそこまで多くの人がやってきたわけじゃないと思うので、まずWasmをどこで知ったんですか?Rubyをどこで知ったんですか?

kateinoigakukun:Wasm自体だと、全然Ruby関係ないんですけど。

shyouhei:もちろん。

kateinoigakukun:Swiftのほうでも僕は活動していて、iOSのアプリをSwiftで書いてたりしてたんですけど、Swiftが好きすぎて、iOS以外の場所でも活用したいと思いました。で、どうやらLLVMに関連するプロジェクトでは、WebAssemblyというのが流行っていると。それを使うと、ブラウザでSwiftが動くという話を聞いて、それにまんまと乗せられて、WebAssemblyの道に走っていったという感じですね。

shyouhei:なるほど走っていった。で、初めて見たときには、もう既にSwiftのほうもそこそこ動くものがあったみたいな感じなんですか?

kateinoigakukun:そうですね。一応Hello worldが動くところまではできているやつがあって、それを実用段階にするために、すごく頑張るみたいな感じでした。

何でRubyでやろうかと思ったかというと、一番最初のきっかけとしては、去年ぐらいに遠藤さん、mameさんのTypeProf for IDEの開発を手伝っていたんですけど、そこでTypeProfのデモのサイトがあるんですね。あれがサーバーと通信して動いているという話を聞いて、これはクライアントサイドでも動いていいんじゃないかなと思って。そういう素朴なところからちょっとずつ真面目に考えるようになって、何とかできそうだなという段階で、笹田さんからRubyアソシエーションの話があったので、真面目に考え始めました。

shyouhei:最初の「これはクライアントサイドで動くのでは」っていう直感は、結局正しかったですか?それとも結構大変だった?

kateinoigakukun:あー、そうですね。

shyouhei:裏側がどうなっているか全然知らない時に、これ動くんじゃない?みたいな直感があったと思うんですけど。

kateinoigakukun:その時には、Pythonがブラウザで動くことはわかっていて、それもCPythonがWasmにコンパイルできることもわかっていたので、何とかなるんじゃないかなと。

shyouhei:(笑)

kateinoigakukun:(笑)。Swiftでコンパイラをやっていたので、そのコンパイラを作るよりは、Cのアプリケーションをどうにかするほうが、まだお手軽なんじゃないかな、ということで、どうにかなるんじゃないかと思ってました。

shyouhei:作りきってるんで、すごいですね。

kateinoigakukun:(笑)

SwiftとRuby(あるいはPython)、どっちがWasm対応大変?

hogelog:追加で聞いてもいいですか?SwiftのWebAssembly対応と、RubyのWebAssembly対応、どっちが大変でしたか?その前かな、Pythonはできているっていう話だったんですけど、Pythonでは必要のなかったものが、Rubyではあったのかを聞いてみたいです。

kateinoigakukun:まずSwiftとの移植の比較ですけど、さっきも言ったように、コンパイラを直すっていうのは超大変なんですね(笑)。なぜかというと、コンパイラが間違った結果を出力する、で、その間違った出力をデバッグするのは、すごい大変。さらにWebAssemblyの場合は、ちゃんとしたデバッグがないんですよ。そうすると、例えばinstruction-levelで実行を進めていって「あ、ここでメモリが壊れてるな」みたいなところを探さないといけないんですけど、そういうのができないので、まずデバッガを作るところから始まるんですね(笑)。

hogelog:GDBとか、LLDBみたいなものがないってことですね。

kateinoigakukun:そうですね。なので、それと比べると比較的(一同笑)Rubyのほうがとなります。

hogelog:なるほど。

kateinoigakukun:で、Pythonとの比較だと、僕はCPythonの実装に詳しくないんですけど、それこそ保守的GCはそこまで難しくないんですけど、比較して、特に難しいところはないんじゃないかな。

hogelog:コメントで笹田さんが、Pythonはリファレンスカウント、参照カウントだから、多分そこら辺が楽なのではっていう指摘をしていますね。

kateinoigakukun:そうですね。ただ、CPythonの有名な移植のPyodideっていう、ブラウザ上でWebAssemblyにコンパイルされたCPythonがあるんですけど、PyodideではEmscriptenっていうまた別のツールチェーンを使っていて、Emscriptenはいろいろリッチなハックもいっぱいやっているんで、何でもできて、移植性は超高いぜみたいな感じなんですよね。今回のRubyの移植は、wasi-sdkっていう、また別のかなり薄いsdkを使っているので、そこがちょっと大変だったかなという感じもありますね。

Ruby to WasmなJIT、Wasm自体のJIT

hogelog:ありがとうございます。別の全然違う質問なんですけど、Wasmの処理速度を考えていくと、速度っていうと、今回のRubyKaigiでもJITの話がいっぱいあったじゃないですか。Wasmで考えると、まずRubyのコード、構文木をWasmのVMコードに落としていくJITみたいなものとか、Wasmのコードを本当の機械語に翻訳して、実行していくWasm処理系とかってあったり、考えたり、やっている人とかっていたりするんですか?

kateinoigakukun:でもRuby to Wasmなコンパイラは、見たことがあるかもしれない。ちょっと名前は出てこないんで、夢かもしれないんですけど。

一同:(笑)

hogelog:それこそYJITがWasmに対応していくとか、そういうのは原理的には可能になる?

kateinoigakukun:そうですね。ただ、結局VMというか、動的な部分を実装するにあたって、ランタイムの部分が、かなり占めてくると思います。例えばコンパイルすることによってサイズがぐっと減るみたいなことは、実はないんじゃないかなと。

hogelog:Wasm実行系のことで言うと、Chromeとか、ブラウザの中だと、WasmのVMコードがJITコンパイルみたいにされてたりするんですかね。

kateinoigakukun:そうですね。WebAssemblyがブラウザで動くときは、Chromeだと多段なJITになっていて、最初はすぐコンパイルできるけど、それなりのコードを吐くみたいな、そういう一般的なJITのパイプラインを通してやっています。

hogelog:ありがとうございます。動いてるプログラムをWasmに落とすのは難しいかもっていう、笹田さんがコメントで書いてくれてましたね。たしかに。

kateinoigakukun:そうですね。動いているプログラムをWasmに落とすのは難しそうだな。

hogelog:サンドボックス、セキュリティ系のそれを突破できなそうっていう感じですか?

kateinoigakukun:そうですね。それで面白い話で言うと、Firefoxの実装が、外部のライブラリのセキュリティ要件をコンパイル時にWasmにコンパイルできれば、変なことはしていないという前提に基づいて、Firefoxの一部のモジュールをWasmに1回して、それをさらにネイティブにコンパイルするっていうアプローチを取ってたり、そういう面白いWasmの特徴みたいな話はいっぱいあると思います。

hogelog:いろいろ面白いことがあるんですね。ありがとうございます。

Wasmフレンドリーな言語はありうるのか

fujimura:僕から追加で質問です。SwiftとRubyをやってみて、Wasmフレンドリーな言語の特徴って何かありそうですか?

kateinoigakukun:かなりあると思っています。現状メジャーなWasm対応をしている言語は大体LLVMをベースにしてると思うんですけど、LLVMの中間表現のLLVM IRって、レジスタマシンなんですね。で、レジスタマシンなんですけど、出力先のWebAssemblyは、対してスタックマシンなんですね。まずそこの変換で一定の非効率が出てきます。

あとは、Wasm上ではループだったり、structuredな制御構造が記述されるんですけど、それに対してLLVMだと、basic blockっていうジャンプ命令で頑張ってそういうのを、ループとかを表現するんですけど、そういうところで一回下がった表現が、もう一回上がんないといけないんですね。そういうアルゴリズムをRelooperっていうすごい難しいアルゴリズムがあって、やたら難しいんですけど、そういうところで非効率がある。なのでWasm用に設計された言語っていうので、素直に翻訳していく言語があってもいいかなと思っています。

fujimura:何か出てきそうですね。

Swift、コンパイラ、プログラミングに興味をもったきっかけ

fujimura:ここで質問をいただいたので、聞いてみようと思います。ひとつめが、

「Swiftへコントリビューションしようとしたきっかけは?」

kateinoigakukun:SwiftってXcodeに何年か前から入ってるんですけど、当初すごい壊れてたんですね。

一同:(笑)

kateinoigakukun:で、ちょっと変なことをすると、すぐにコンパイラがクラッシュする。コンパイルエラーじゃなくて、コンパイラがクラッシュするんですよ。で、コンパイラがクラッシュすると、そこにスタックトレースが出てくるわけですね。そうすると中間表現を挟んで、LLVM IRを出力して、最終的にオブジェクトファイルを作るんだなみたいな、そういうスタックトレースから、だんだんコンパイラの気持ちがわかってくるんです。で、これをどうやって直したらいいかみたいなところを考えて、だんだんコードを読んで、コントリビュートし始めました。

fujimura:すごい。Appleの洗練されたリクルーティング手法を感じますね。

一同:(笑)

fujimura:じゃあもうひとつ、

LLVMコンパイラに興味を持ったきっかけは?」

kateinoigakukun:それもそのつながりで、どんどん掘っていくと、そこにたどり着くんですよ。

fujimura:それはそうだが(笑)。じゃあ、その前は普通にアプリケーションを書いていたんですか?

kateinoigakukun:そうです。普通にiOSのアプリケーションを開発していました。

fujimura:ついでに聞いちゃうんですけど、そもそもいつコンピュータを触り始めたんですか?

kateinoigakukun:僕はコンピュータより先にiPadを触っていて。で、親からiPadを渡されると当然制限されてるんですね。ゲームも入れられないし、ブラウザしか動かないわけですよ。

shyouhei:ここでしゃべっても大丈夫なネタ?

kateinoigakukun:大丈夫です。そうすると、ブラウザのアドレスバーにJavaScriptが書けることを発見するんですね。

一同:(笑)

kateinoigakukun:で、それを遊び場として(笑)

fujimura:実行環境を手に入れてしまった。

kateinoigakukun:ブックマークレットで遊ぶみたいな感じでした。

fujimura:そこからどうして?そのときは、何かプログラミングをやってたんですか?

kateinoigakukun:それでiOSがいい環境だなと思って、でもJavaScriptでできることはすごい限られてるんで、やっぱりネイティブのアプリが作りたくなって、Swiftをやり始めました。

fujimura:じゃあ、最初はアプリケーションを作るほうからいったんだが、だんだんはみ出て見えるものから、下に潜っていくことになったというか。

kateinoigakukun:そうですね。

fujimura:理論上はわかるけど(笑)

Wasm以外の関心

fujimura: Wasm以外で何か興味を持っているところ、Wasmの近くでも、遠くでも、コンピュータでどんなところがあるんですか?

kateinoigakukun:それこそ、今回RubyKaigiでいっぱい話のあったJITの話とかは割と興味がありますね。速度というよりは、どう実装するのかみたいなところで、お手軽にどれだけ早くできるかみたいなところに、興味があります。あとは、最近気がついたんですけど、僕は基本的なモチベーションとして、いろんなところで変なプログラムを動かしたい気持ちがあって、そうするとプログラムのサイズに制約があったりするので、最近はプログラムのサイズを最適化するっていうのを研究でやっていたり、そういうところに興味があります。

fujimura:ありがとうございます。

hogelog:面白いなという気持ちで聞いてました。いろんなところで動かしたいものがあって、発表の中にあったirbがブラウザの中で動くとかも、昔のkateinoigakukunさん、小さかった頃の環境が制限されていた頃の自分を救うような成果物を作っていていいなって。

一同:(笑)

hogelog:制限されたiPadを持っていて、プログラミングを楽しみたい、昔のkateinoigakukunさんが今もしかしていたら、irb-wasmを渡せば、楽しくプログラミングできるかもしれないって思いました。

kateinoigakukun:そうするとRubyネイティブな人材が。

hogelog:Rubyネイティブな人材になって、やっぱちょっとあれだから、エラーとかも、出しとかないといけないですね。ちょっと感想になっちゃいました。

LLVM難しくないですか〜プログラムの読み方

shyouhei:LLVM、僕も読もうと思って挫折した経験あるんですけど、あれ超むずくないですか?

kateinoigakukun:超むずいっすね。

shyouhei:大きいし、Swiftが読めるぞって思って、LLVMに突撃して、そんな読めるようになるようなレベルではないと思うんですけど(笑)。どこで読み始めましたか?

kateinoigakukun:最初から読めたわけではなくて、もちろんC++は全然読めなかったので、まずそこから。僕は大きなプログラムを見ていくときに、デバッガで止めて、値をインスペクションしながら追っていくことが多くて。プログラムを書いて、それがどうコンパイルされるのかを見るときに、これがどこのパスを通っているのかをすべてのケースを考えるんじゃなくて、特定のケースだけを追っていって、全体像をつかんでいった感じです。

shyouhei:じゃあ、Rubyを移植するときも、それと同じように、デバッガを使ってブレイクポイントを立てながらやってみた感じですか?

kateinoigakukun:そうですね。

shyouhei:おおー、すごいですね。C++をなるべく避けながら、LLVMに習熟する方法ってありますか?これは知りたいね。僕も知りたい。

kateinoigakukun:(笑)。何だろうな。でもC++の難しいところを凝縮したみたいなコードベースなんで。

shyouhei:LLVMC++って、使い方が特殊なんですよね。制限がかかってたりして。そういうのもあって、余計に読みづらかったりするし。

kateinoigakukun:ただ、コメントがちゃんと丁寧に書いてあるんで。

shyouhei:それはそうですね。

kateinoigakukun:コメント読めばわかるだろみたいな。

一同:(笑)

kateinoigakukun:これは僕の印象ですけど、強い気持ちで書かれていることが多いので、愚直に読んでいくしかないのかな。あとは、あれですよ。CMakeのビルドシステムを読んでいくと、全体像がわかって面白いですよ。CMakeが読みやすいかは置いておいて。

shyouhei:そうですね(笑)。ありがとうございます。

kateiさんから見たRubyの並列・並行

fujimura:ということで、Wasmの対応されているkateiさんから見て、笹田さんの発表はどう映ったのでしょうか?Rubyの並列・並行周りに対して、Wasm対応している立場から思うことがあったりするんですか?

kateinoigakukun:Wasmはスレッド、一応動くことは動くんですけど、ちょっとなかなか制約があるので、今すぐに直接関連するというわけではなかったんですけど。Ractorはすごい面白くて、Swiftをやっている身からすると、Swiftでは協調したM:Nスレッドになってるんですね。それに対して、Rubyはプリエンプティブなモデルになってると思うんですけど、それに加えて2レイヤーになってるのがすごい面白かったですね。あれはやっぱりインタプリタ特有の話かなと思ったり、コンパイラで生成するような言語ではない話だったので、すごい面白かったです。

Ruby on Wasmを簡単にする裏技はあるのか

fujimura:ありがとうございます。あとは、これは雑談っぽいやつなんですけど、Rubyが裏側でもっとWasmを使って簡単に動くようにするための裏技というか、こういうむちゃをすれば、もっと簡単に動くはずだみたいなのってあるんですかね。

kateinoigakukun:(笑)

fujimura:自分がもしWebKitを好きにいじれるならみたいな。

kateinoigakukun:まずはインタプリタを埋めます。

fujimura:やっぱそうですよね。

kateinoigakukun:JavaScript、ずるいですよね。

fujimura:いや、そうなんですよね。

kateinoigakukun:Swiftはもともと入っていたり、強力なJITコンパイラもあるし。それに関連して速度の話をすると、WebAssemblyって速度で宣伝していることがよくあるんですけど、僕は意図的に、ちょっと最近それへの明言を避けています。なぜかというと、ちゃんと触るとそんなに速くないんですね。ちゃんとしたアプリケーションで比較してみると、そんなに速くないと。ネイティブ並みっていうのは、過大広告なんじゃないかなと思っていたり、そういうところが、やっぱりブラウザにビルトインされている言語、JavaScriptだと、そこのレベルが全然違いますねという気持ちがあります。

fujimura:どうやったら、ChromeRubyをインストールできる日がくるんでしょうね。

一同:(笑)

kateinoigakukun:どうにかGoogleに入って(笑)

fujimura:そうですよ。Rubyで入ってやってくれるかな。でも、僕はkateiさんのトークを聞いていて、そういう日もないわけじゃないんだろうなっていう世界を、Wasmは切り開くんじゃないかなみたいな想像とかはしましたね。

kateinoigakukun:Rubyインタプリタが、ネイティブで入ることは恐らくないとしても、Wasmモジュールとしてキャッシュされているみたいなことはあるかなと思います。

fujimura:そうですよね。それができるとEdgeWorkerで、Rubyデプロイがすごい気分よくできるんじゃないかなってのがあるんですよね。

kateinoigakukun:そうですよね。結局プラットフォーム側としては、Wasmをサポートすれば、自動的にいろんな言語はサポートできると。で、Rubyを書いてる人も、いろんなプラットフォームでRubyが書けると。Win-Winなんですよ。

デバッガでコードを追う秘訣

fujimura:ちょっとこの話も広がりそうなんですが、質問をいただいているので、読み上げます。

「デバッガで追いかけていくとき、どこを読んで、どこを読まないみたいな判断をどうやっているんでしょうか。全体がわかってないと、どこを飛ばしていいかわからなくて、結局全部読むことになりそうなのが気になってます」

kateinoigakukun:なるほど、確かに。それはそうですね(笑)難しいですね。デバッガで追っていると、やっぱり難しいところが再帰だったり、何回も同じブレイクポイントに止まっちゃったりとか、それこそ分岐でどこを飛ばしていいのかとか、わかんないんですけど、そういうところはプリントデバッグかな。

一同:(笑)

shyouhei:言ってること、全部普通にやってる。

fujimura:そうなんですよね。勘とか、あるんですか?

kateinoigakukun:勘は、いやでも勘でやると、ろくなことないんで(笑)。二分探索を途中までやってたけど、もうここまで範囲が狭まったから、ここの範囲ならここだろうと当たりをつけてやると、全然違うところにバグがあったり。そういうことが往々にしてあるので、勘はできるだけ避けたいですね。

fujimura:じゃあ、普通に二分探索を愚直にやるところから始まっていくんですかね。

kateinoigakukun:そうですね。銀の弾丸はないというか。

fujimura:銀の弾丸がないのに、ここまできてること自体がすごいみたいなのが、われわれの感想なんですけど。

Rubyに欲しいSwiftの機能や文法

fujimura:質問がきてますね。

「Swiftの機能、文法、実装などで、Rubyに取り入れたらよいんじゃないかというものなどありますか?」

kateinoigakukun:Swiftだと、プログラム側に制御の動きがあるところは書かないといけない。例えば例外を投げ得るところはtryって絶対書かないといけないんですね。そういうところをプログラマーにマークさせるっていう言語なんですけど、そうすると言語処理系からすると、すごい最適化しやすいんです。絶対に、例外が起こり得るところにはtryって書いてあるから、その次の行でだけ例外チェックをすればいい、そういうすごい簡単な最適化ができるようになるので、そういうマーカーを入れたらいいと思います。

一同:(笑)

kateinoigakukun:Rubyっぽくなくなると思うんですけど(笑)。最適化の面から言うと、そういうのが入ってるとうれしいなと思うんですけど、でもやっぱりRubyの書き味を損なう気がするので、まあ冗談ですね。

一同:(笑)

fujimura:これは、じゃあ逆に卜部さんに質問ですけど、Rubyってそういうある意味機械におもねった機能や文法って、入らなそうなイメージがありますが、どうですか?

shyouhei:そうですね。でも、safe-navigation-operatorとかは、Swiftのほうが早いんですよね。もちろんRubyに入ったのは、Swiftのsafe-navigationとはちょっと違うんだけど、それにしても何か便利だなと思ったことを入れるっていうのは別になくはないので、うまくRubyの書き味にフィットするかたちなら、全然入るかなと思います。

tryがほしいっていうのも、tryがあったほうが、ユーザーもわかりやすいじゃないですかみたいな話も実際あるので、このプログラムのこの行まできたら、ここから下はnullがこないはずっていうのをプログラムの中で書きたいとかも言われたりするんですよね。must notみたいなのを教えてみたいな。そういうのをプログラムとしても表明しておくほうがわかりやすいと言われると、うん、そうかもねと思ったりするので、だから最終的には作者のまつもとさんをどういうふうに説得するかなんですけど、説得するパスがあればいいんじゃないかなって僕は思いました。

fujimura:ありがとうございます。何かコメントがあれば。

kateinoigakukun:便利なものがあれば、うれしいのはうれしいけど、Rubyにどうフィットさせるかっていうのはやっぱ難しそうですね。

Wasmのモジュール、RubyでWasmを使う話

fujimura:確かに。次の質問です。
iPadブックマークレットで遊ぶ場合、キーボードって何使ってるんでしょうか?」

kateinoigakukun:iPadに表示されるソフトウェアキーボードです。

fujimura:あれでプログラミングしてるわけですね。

kateinoigakukun:ぽちぽちやっていくわけですよ。

fujimura:なるほどな。

hogelog:さっき話がありましたけど、WebAssemblyのモジュールで、Rubyのランタイムみたいなものが共有していけるモジュールのようなものって、既に概念とかは議論されていたりするんですか?

kateinoigakukun:そうですね。WebAssemblyファイル、.wasmファイルっていうのが仕様ではモジュールっていう表現をされていて、実はあのモジュールを連結する、リンクするっていう提案もされています。JavaScriptのES Modulesってあると思うんですけど、それに割とインテグレーションしやすいような仕様の設計にはなっています。なので、そういうところがモジュール同士のリンクができるようになると、例えばruby.wasmっていうファイルがあったとして、現状は今拡張ライブラリをリンクしようとすると、ダイナミックリンクができないので、ruby.wasmのインタプリタ実行ファイルをもう一回リンクし直さないといけないんですね。なんですけど、そういうモジュール同士のリンク、Module Linkingっていうプロポーザルがあるんですけど、それが成熟していくことで、Wasmモジュールを再利用して、いろんな新しいプログラムを構成するっていう、プログラムスタイルができるようになるはずという感じですね。

hogelog:そうなっていくと、nokogiriのFat gemが、Wasmバイナリーもnokogiriが提供するようにとか。

shyouhei:CDNから出てくるってことですよ。

一同:(笑)

hogelog:CDNから降ってきてほしいですね。

kateinoigakukun:そうですね。それこそRubyをWasmにする話じゃなくって、RubyでWasmを使う話。拡張ライブラリをWasmとして配布して、そしたらFat gemにしなくても済むし、みたいなところはあると思います。

hogelog:確かに。いいですね。何か夢が広がるというか、どうなっていくんだろうっていうのがすごく楽しみですね。

shyouhei:でも僕も今後の見通しっていうか、何やりたいですかみたいな話を聞きたかったので、大体似たような感じになったかな。今後、一応irbが動くとかっていうところまではきたじゃないですか。このあと、何をやっていきたいですか?

今後の構想

kateinoigakukun:今後何をやってこうかなというのは、ふんわり考えていたんですけど、それこそ拡張ライブラリの配布形式としてWasmを使うだったり、あとはそれこそバーチャルファイルシステムの実装の拡充だったり、現状あれなんですよね。Read onlyなファイルシステムになっているので、例えばネットワーク越しに、Rubyファイルを取得するみたいなところもできるかなと思っていたり。

shyouhei:すごい夢が広がる。

kateinoigakukun:そういうところができるとかっこいいかなと思っています。実用的な直近の問題で言うと、冒頭のほうで話が出ていたAsyncifyっていうツールがあるんですけど、それが現状プログラムの制御をunwindするというか、シリアライズする仕組みの、そこのバッファのサイズが固定なんですね。なので、例えばCRubyの中で、Cの関数がはさまるようなメソッドのコールスタックになっていると、

shyouhei:すごく長くなるやつありますよね。

kateinoigakukun:そう、eachとか入っちゃうと(笑)、すぐにそのスタックが、バッファが尽きちゃうんですね。そういうところを可変長にするために、GCCのSplit Stackっていう。

shyouhei:Split Stackやるんだ。すごい。

kateinoigakukun:Segmented Stackみたいな、そういうやつをAsyncify上でやりたいなって思っています。

shyouhei:これはすごく大きな話なので、ぜひ頑張ってほしいです。

kateinoigakukun:(笑)

shyouhei:スタックとヒープが入り乱れてくるよね。やると、結構大変ですよね。

kateinoigakukun:そうですね。ただ、今回Asyncifyの簡単なところは、全部ヒープなんで。

shyouhei:一応、素のパソコンとかでやるよりは、簡単なはずみたいな。

kateinoigakukun:そうですね。理論できた(笑)。

shyouhei:すごい(笑)。頑張ってください。ありがとうございます(笑)。

fujimura:ということでお時間ですので、まだまだ聞いてみたいことはあるんですが、終わろうと思います。kateinoigakukunさん、ありがとうございました。

kateinoigakukun:ありがとうございました。(完)

 

vol.2に続きます。

深堀りRubyKaigi 2022 文字起こしレポート一覧

記事の感想をお待ちしております!#fukabori_rubykaigi_2022 をつけてツイートしていただけると嬉しいです。

 

イベントの感想まとめ▼

 

STORES Product Blogの更新はTwitter @storesinc_tech でお知らせしています。ぜひフォローしてください!