夢が広がる未来の話、言語デザインのむずかしさ。深掘りRubyKaigi 2022 with ko1 & kateinoigakukun 文字起こしレポートvol.3

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

実行環境がいろんなところにあるかもしれない未来

fujimura：全員での質疑応答コーナーを始めます。では、僕から笹田さんに質問です。kateiさんの発表をコンカレンシー、パラレリズムをやっている笹田さんから見てどうだったか、及びWasmをどう見ているかを、ぜひお聞かせいただきたいです。

ko1：並行処理をやってる人から見たkateiさんっていう、なかなか難しい質問ですね。

一同：（笑）

ko1：ファイバーにいきなり対応しちゃったのは、すごいですよね。そこからやるんだと思って、びっくりしました。まずスレッドの話をすると、ファイバーができるんだったら、スレッドもそんなに難しくなくできると思います。ただタイムスライスするのが若干めんどくさいかもしれないですけど、性能を考えなきゃできるので、やってもいいのかなと。ただただすごいですねという話しかないですね（笑）。

Wasmに関しては、実はkateiさんがクックパッドのインターンに来てくださった頃、一緒にミーティングをしてたんですけど、大体kateiさんにWasmを教わる会みたいになってましたね。WasmやWASIに関しては、教えてもらう会みたいな感じになって、大変助かりましたし、理解が深まりました。「今この仕様でこういう議論があるんですよ」みたいなこと言われて、何でそんなこと知ってんの？と、ちょっとびっくりするような知識の深さを披露していただいて、すごかったです。

テクニカルな話で言うと、Wasm一般じゃなくて、Ruby Wasmの話になっちゃうんですけども、実行環境がいろいろポータブルになるので、C extensionのサンドボックスとしてWasmを使って、そこからさらにgemを使うみたいな話があります。だいぶわくわくする話ですね。

あとブラウザサイドでRubyを使う話として、今はRailsってサーバーサイドでサーバーサイドレンダリングが普通じゃないですか。クライアントで、Rubyは動かなかったから。でも、Rubyが動くようになったんですよね。そうすると、例えばERBの処理をクライアントサイドに持ってきたら、JavaScriptでJSONの色づけ係みたいな、あれができるようになるわけですよ。そういう感じで、アーキテクチャがちょっと動いてきそうだなと思って、そのダイナミックさに何かわくわくする感じがします。

kateinoigakukun：クライアントサイドに処理が移っていく話で言うと、それこそWasm以前の技術としてOpalがありましたよね。あそこら辺の資産をどうにか再利用できないかなと思っていたりします。

ko1：Wasm版RubyはMRIと大体同じなので、そこはだいぶ強いですよね。Opalは、Opal特有の制限があって、これができる、これができないっていうのがあったと思うんですけども。Opalで欲しい機能ってあったんですか？

kateinoigakukun：特にないんですけど（笑）ある程度ライブラリの、例えばjQueryのバインディングが整備されてたり、今どきあれですけど（笑）という感じで、グラデュアルに推進していくためには、あってもいいのかなと思ってたりしています。

fujimura：今、気づいたんですけど、React.jsのJSXをERBで書く世界がくるわけですね。想像もつかないですけど。いやあ、すごいよな。やっぱり未来はまだわからない感じですよね。

ko1：そうですね。あるプログラムをどこで動かすかって、すごい大きな目で見る、遠い視線で言うと、分散計算の話になるんだけど、その分散計算のための提案って、すごい昔、70年代ぐらいからいろいろ盛り上がってたんですよね。例えばアクターが、まさにその辺からできた概念だったり、オブジェクト指向もその辺が絡んだ話もあったんですけど。

そういう意味で、実行環境がいろんなとこにあると、夢が広がる感じがしますね。その中でRubyがいろんなとこにあって、あっちで動かして、こっちでも動かして、サーバーサイドレンダリングで最初はキャッシュしといて、ぱっと返すんだけども、データを送って、あとはクライアントサイドでやるわっていうのは、やろうと思えばできなくはない。理論的にはできる。本当にやるとうれしいかっていうと…

一同：（笑）

ko1：だいぶ疑問ですけど。例えば今、Wasm版Rubyは圧縮して10MBみたいな世界ですよね。で、それがペイできる。例えば業務システムだったらペイできるかもしれないけど、エンターテイメントシステム、エンターテイメントだったら、画像は十分大きいからできるかな。ある種のサイトでは重すぎるとか、いろいろ制約があると思うので、その辺できるところ、できないところみたいな話はあるかと思います。下手にその道に突き進むと、Javaのランタイム、Java Web Startみたいな感じになっちゃう。

一同：（笑）

ko1：使えなくなっちゃうかもしれないけど、夢は広がりますね。

fujimura：そこら辺は、Wasmのモジュールバインディングがくると、また話が違ってくる感じなんですかね。

kateinoigakukun：そうですね。それもありますし、Ruby インタプリタ自体のサイズもいろんなやり方で減らせるかなとは思っています。10MBはちょっと配布には厳しいけど、全部圧縮して1MBにできたら、いろんなところに配れてハッピーみたいな感じのシナリオをできるといいなと思ってたりします。

fujimura：10MBでも、もしかしたら1回読んじゃえば、あとは動くみたいなタイプの、キャッシュできるものだったら、また違うかもしんないですよね。

kateinoigakukun：そうですね。初回のローディングがクリティカルになるアプリケーションだと、ちょっと厳しいですけど。1回ロードしてしまえばOKなアプリケーションはよくあると思うので、そういう現状のRubyでもうまく刺さるようなアプリケーションの例をどしどしご応募ください。というか、アイデア募集中です。

fujimura：ですね。

もし無限のパワーと気持ちがあったら

ko1：kateiさんに質問なんですけど、今回で大体Rubyがわかったじゃないですか。じゃあ、WasmネイティブにRubyを作り直そうっていうアイデアはあったりしますか？

kateinoigakukun：そうですね。Wasmネイティブっていうと、要はRuby to Wasmというか、そういうコンパイラというか。

ko1：どういうふうにするかは置いといて、例えばCRubyの代替を作るっていうのはひとつですよね。AssemblyScriptみたいに、Wasmにコンパイルしやすい仕様にする、言語自体を変えてしまうっていうのもひとつ。だけど、MRIの構造がいろいろと気持ち悪いっていう話があるので、その気持ち悪いところをはずすMRIみたいなものを原理上は作れると思うんですけど、何かそういうのってアイデアとしてはありますか？

kateinoigakukun：現実的に考えたときに、メンテナビリティとかあるので、絶対にやらないなとは思うんですけど。

ko1：（笑）

kateinoigakukun：（笑）もし無限のパワーと気持ちがあったとしたら、やりたいこととしては、Rubyのダイナミズムをある程度削りたいなと思っています。例えば、関数呼び出しのインライニングを静的にできるところが、やっぱり欲しくなってきますね。メソッド呼び出しで、JITをしなくてもインラインできるようにしないと、Wasmでは全然うれしくないんですよね。1 Wasmモジュールで完結したプログラムとして実行する場合に、JITっていうのは絶対考えられないので、どれだけインダイレクトコールを減らすかっていうのが、Wasmネイティブにしたときに、性能で気になってくる部分だと思っているので、そのあたりをどうにか。言語側に制約を入れるのか、もしくは何かすごい頑張って、すごい静的解析で読み切るとか、現実性でいうと厳しいかもしれないけど、Wasmネイティブにするぐらいだったら、そのぐらいはやりたいなと思います。

ko1：ありがとうございます。

shyouhei：ブロックがあるじゃないですか。関数呼び出しなら、話は早いんだけど、ブロックがあって、eachとかでブロック渡すじゃないですか。ブロックってクロージャーだから、関数的なやつなんだけど、ここには必ずこのブロックがきますとは、なかなか言えなくって、eachだったらeachで、中身って毎回違うじゃないですか。だから、そこが多分インランニングするときすごく難しいと思うので、多分そこに一段階なんかアイデアが必要かなと思いました。

kateinoigakukun：呼び出された側が、静的にわかっている場合は、callerに全部インライン化して、で、ブロックもそのままぺたっと貼りつけられないですか。わからない？

shyouhei：わからないと思う。

ko1：リテラルでブロックが書いてあれば、わかるじゃんっておっしゃってるんですよね。

shyouhei：ですよね。それはリテラルで書いてある場合のみなので（笑）なかなか難しい。

ko1：（笑）

kateinoigakukun：Swiftの場合もそういう問題があって、インライナブルでない関数に対してクロージャーを渡したときに、深いところでは静的にわからないので、結局間接呼び出しになるところはあります。例えばブロックをどんどん引き渡していって、処理をつないでいく、深いところまでブロックを持ち回していくのって、どのぐらいあるんですか。全然アプリケーションの肌感がわかんないんですけど。

shyouhei：どうでしょう？めっちゃやってる印象ではありますが。

kateinoigakukun：なるほど。それは大変っすね。

一同：（笑）

kateinoigakukun：ブロック持ち回りをやるのって、どういう時なんですか。継続をやりたいという話ではないですよね、Rubyだと。

shyouhei：そうですね。loan patternみたいな場合が多くて、前処理をやって、次の処理に投げて、ブロックか何かが処理終わったら、片づけて、ネストしていくのが多い印象があります。

kateinoigakukun：なるほど。例えばそういうのが、C++であるRAIIみたいな。

shyouhei：そうね。RAII欲しいですね。欲しい。

kateinoigakukun：そういうブロックの間接呼び出しをなくす（笑）アイデアで何とかならないかな。

shyouhei：わかりました。ありがとうございます。RAII、欲しいときありますね。それか、ブロック抜けたら勝手に終わってくれるみたいなのが欲しい。

kateinoigakukun：（笑）、deferだったら入らないですかね。

shyouhei：deferが欲しいっていうプロポーザルもありましたね。どうなったか、ちょっと覚えてないけど、何かあった気がしますね。

ko1：deferは、本当に入れていいのかみたいな、名前はどうするとか、ブロックでいいじゃんっていうとか、いろいろ意見がありますね。

言語デザインって難しい

hogelog：Rubyプログラム内にxmlみたいに直接書けるようにしたらいいんじゃない、て、笹田さんが言ってたんでしたっけ？

ko1：はい。heredoc extension*1ね。

hogelog：そう、さっきのクライアントサイド、サーバーサイドで動くことを考えていくと、JSXが書けるとか（笑）JavaScript界隈では、xmlを中に直接書きたいっていうのが定期的に生まれてきて、そうしているわけですけど、Rubyでもその辺は割とまじめな提案なんですか？

ko1：まじめか、まじめじゃないかで言うと、今はあまりまじめに取られてないです。けど、この話はほかの言語から言うと、JSXでJavaScriptにタグを埋め込んでしまう話とか、あとC#だとLINQとかでSQLを書くっていう話があるじゃないですか。で、それはよく考えられた文法だと既存の言語、例えばC#とコンフリクトしないので、何となくSQLっぽいものが書けるよさがあると。この話のバックグラウンドとして、LINQももしかしたら、Rubyに入れられるんじゃないの？みたいな雑談をしてて、まじめに話しだしてるんだけど、私LINQ大っ嫌いなんですよ。

一同：（笑）

ko1：なので、やるんだったら、こっちのほうがいいんじゃないの？っていうので、カウンタープロポーザルとして出したバックグラウンドがあります。好き好きだと思うんですが、個人的には別の言語が交ざるのが嫌いなんですよね。ヒアドキュメントだと、ここからここまでは違うみたいな雰囲気があるので、それでいいんじゃないですかっていうのが僕の提案です。

LINQみたいなのは、エディター上で何となくRubyっぽい顔をしながら、実はRubyの言語ではないものが入ってて、気持ち悪い。その話をしたら、LINQがいいんじゃないのって言ってる人たちから「いや、エディターがちゃんとその辺をきれいにそれっぽく表示してくれる。そんな古いエディターを使ってるのが悪いんだよ」みたいな話をされて。どっちがどうなるかはわかりませんが（笑）言語デザインって難しいですね。ただ、クライアントサイドで動かすか、サーバーサイドで動かすかっていうのは、別に.erbファイルなり、.hamlファイルなり、.slimファイルなりでも、同じことができるはずなので、文法とは独立した話なのかなと思います。

hogelog：たしかにそうですね。

fujimura：JSXは、JavaScriptのストリングインターポレーションがあまりにもしょぼいから、生まれたのではないかっていう気もするので、それがRubyだと、あまり問題にならないような気もしますけどね。

ko1：タグはタグとして、かっこよく書きたいっていうのは、SQLはSQLっぽくかっこよく書きたいっていうのと同じように、ニーズとしては十分わかります。なので、あとは言語デザインをトータルでどう設計するかかなとは思います。

fujimura：ありがとうございます。ここでアルフォートおじさんから質問ですが、

「Ruby Wasmで効率よいかさておき、RailsのHamlのレンダリングをCDN上でやるとかできるのかな。」

kateinoigakukun：どうなんでしょう。RailsのHamlがわからないんですけど、少なくともHaml自体はWasmで動くことがわかっているので、できるんじゃないですか。レンダリングだけですよね。データフェッチも、その裏側でやればいいだけなので、CDNでやるとしたら、FastlyのCompute@Edgeだと、裏側のオリジンにデータをフェッチする機能と、その機能を使ったWasmプログラムで、何かしらHTTPリクエストにお返事を返すというアーキテクチャなんですけど、そういうかたちでやれば、エッジでHamlを動かして、HTMLを返すというのは十分にできると思います。

fujimura：RailsのビューをSSRすることも、もしかしたらできるかもしれないですよね。夢が広がりますね。

kateinoigakukun：夢が広がる。

fujimura：タイムトゥファーストバイトは、速くなるかな（笑）。

kateinoigakukun：（笑）

fujimura：かもしれない。

kateinoigakukun：どのぐらいうれしいのか、わかんないですけど（笑）。

fujimura：Railsの画面のレンダリング自体は、別に速くならないというか、トータルのコストはあまり変わらないから、でもそこら辺が面白いですよね。何がどうなるんだろうっていうところが。

kateinoigakukun：そうですね。Wasmにすることでうれしくなる、うれしくなり得るポイントのひとつは、Wasmだとプロセスの状態をスナップショットしやすいんですね。これにはいろんな要因があるんですけど、ネイティブのものよりもやりやすい。で、そのスナップショットをとったプロセスを、特にランタイム側で面倒を見ることなく、そのまま実行できるという特徴があります。例えばRubyのインタプリタを起動して、必要なgemを読み込んだ状態で、スナップショットをとっておいて、で、CDNに配ることにすると、ちょっぱやでレスポンスが返せて、うれしいかもしれない。

fujimura：なるほどな。夢が広がりすぎて、無言になってしまった。

kateinoigakukun：ただ、そこをやろうと思うと、CRubyのC APIを頑張って整備しないとできないということがわかったので、ちょっとそのあたりも手を入れないとだめかなと思ったりしています。

fujimura：たしかに。

僕はあんまりmrubyに気持ちがない

fujimura：僕から、主に卜部さんと笹田さんに質問です。僕もあんまりわからない中で話しますので、もし変なところがあったら、突っ込んでください。RubyをWasmでブラウザで動かすとなると、ブラウザの何かをさわったりすることがあると思うんですね。ローカルストレージをさわりたいとか、そういうのって人々が作ったライブラリじゃない、標準ライブラリで欲しいという人が出てくると思うんですよ。そういうrequire ‘localstorage’みたいな標準ライブラリがRubyに入る未来ってあるんですか？

ko1：これはkateiさんが答えられるような感じがするんだけど、WASIっていうのがそのレイヤーになるのかなと思っています。Ruby上でファイルシステムをリードライトすると、普通にPOSIXのファイルシステムのように、リードライトできるっていう層が、WASIと、そのWASIから起動される、kateiさんも作られているバーチャルファイルシステムに当たるので、そこはそんなに変えないほうがいいんじゃないかなと思います。

ただファイルシステム、ストレージに関してはそれでいいかもしれないけども、キャンバスとか、JavaScriptでさわるのが当たり前だったようなリソースは、何らかのかたちでインターフェースを出してあげなきゃいけなくて、そこはもしかしたら標準化はあるのかもしれない。これkateiさんに聞いていいですか？kateiさんはその辺どうあるべきか、実際にある活動とか、ご存じだったりしますか？

kateinoigakukun：個別のAPIに関して、特別なRuby バインディングを作るという話はまだ出ていなくて、それよりもジェネリックなJavaScriptへのバインディングで、どうにかしたい気持ちがあります。例えばRubyKaigiのデモでちょっと出したものだと、イベントリスナーは、本当にwrapperとかはなくて、そのままJavaScriptの関数、メソッドを呼び出す。そういうジェネリックな機能で実現されているので、それである程度の書き味が実現できたら、そのぐらいでいいんじゃないかなという気持ちです。

ko1：標準でWASIみたいな感じで、JavaScript機能へのアクセスを提供しようっていう動きは、まずオフィシャルにはない？

kateinoigakukun：そうですね。基本的にないですね。

ko1：なので、JSをJSっぽく書ければいいじゃんっていうことですね。

kateinoigakukun：はい。

shyouhei：Denoとか見ててどうですか？何かサーバーサイドで、ブラウザっぽいものを頑張って作ろうとしてるじゃないですか。

kateinoigakukun：（笑）あれは、またちょっとレイヤーが変わってくると思うんですけど。結局Rubyから見たときに、どう見えるかというと、JavaScriptがある環境なら、大体同じAPIというか、同じ環境だと信じて、Rubyの中でJavaScriptのチャネルで通信をしていたら、全然違うAPIが返ってきたみたいなことが起きると、ちょっと面倒かなとは思うんですよね。でもそんなにDenoとかで、特に困る話はないんじゃないかなとは思います。答えになってます？

shyouhei：DenoってNode.jsと比べて、ブラウザにあるような機能を実装しようとしてるように見えていたので、そういう方針もあるなと思ったんですよね。それと比べても、JSはごろんとJS直して出せばいいじゃんっていうのは、ちょっと方向が違うと思ったので、Denoの方針をどう見ましたかっていう質問でした。

kateinoigakukun：なるほど。あんまりDenoに詳しくないので、ちゃんと答えられる気がしない（笑）

shyouhei：（笑）じゃあ、次、きている質問を、いろいろ聞きますか。

fujimura：そうですね。じゃあ、1個目。kateiさんへ近藤宇智朗さんからの質問で、

「kateiさんの成果をmrubyで先行してやったりすると、はかどったりするのだろうか。C APIはMRIよりも整備されている印象があるし、ということなんですが、どうなんでしょうか。」

kateinoigakukun：mrubyのC APIはめっちゃ整備されててうらやましくて（笑）CRubyのC APIって何ちゃらオプションとか、何ノードとか、外部に公開するものとしては、ちょっと厳しい感じがあるんですよね。なので、整備されてる方がうれしいというのは、はい。やりやすいというのはそのとおりです。

fujimura：ありがとうございます。ジョーカーさんから質問をいただいていて、

「N:Mスレッドに関する話で、繰り返しの質問になってしまうのかもしれませんが、ウェブアプリケーション文脈だと、大体IO待ちになるので、CPUコアを使いたいというよりは、コネクションハンドルは大量に保持するオーバーヘッドを減らせるとよいなと思っていて、Ractorを使わなくても、そういう効果が得られる可能性はありますか。特にhttp2以降だと、コネクション張りっ放しになることがあるので、素人目には意味ありそうだと思ってます。」

とのことですが、笹田さん、どうでしょうか？

ko1：効果があると思います。ファイバースケジューラーが、そのためにRuby3.0から導入されているんですが、それとほぼ同じ効果がM:Nスレッドを使うと得られるんじゃないかなと思います。

fujimura：ありがとうございます。近藤宇智朗さんからmrubyの話の続きで、

「単純にmrubyはコードベースが小さいのと、Luaとかのように、一部機能を完全切り離したりできるので、やりたいことを先に経過的（？）にやりやすくなるのかなというぐらいでした。」

kateinoigakukun：mrubyだと、コンポーザブルにできてうれしいというのは、そのとおりだと思います（笑）mrubyで動かしたいアプリケーションがある場合は、そのほうがうれしいですよね。僕はあんまりmrubyに気持ちがないので。

一同：（笑）

shyouhei：全部mrubyでよかったんやで。

kateinoigakukun：mrubyでみんなハッピーになるかなって。

hogelog：ちょっと聞いてみたいのが、Rubyのプログラムを書く人からするとmrubyとCRubyは同じようなプログラムを動かせるものとして見てる。けど、kateiさんから見ると、mrubyとCRubyは全く別のプログラムだから、今のCRubyへの気持ちは、mrubyには特に繋がらない感じなんですかね。

kateinoigakukun：C extensionがあるようなライブラリが、動かなそうだなというのと。動かないんですよね?

hogelog：うん。

kateinoigakukun：そうするとやっぱり、かなりのgemのエコシステムが使えなくなっちゃうのが惜しいなと思っていて。制約された言語でプログラマーがすごく頑張るより、言語処理系のほうで、どうにかプログラマーを楽にして、効率的というか、サイズ面でも、速度面でも、ソフトウェアのアーキテクチャ的にも、きれいな解決になるほうが僕は好みなので。フルセットのCRubyを頑張るほうを好むという、完全に好みの問題ですね（笑）。

hogelog：好み駆動、いいですね。

shyouhei：ひとついいですか。Wasmを使って、サーバサイドでいろいろやろうみたいな話が、今日は出てきてたんですけど、話を聞いていて思ったのは、手元のネイティブアプリって、Wasmを使うと楽しそうだなって思って。ネイティブアプリってダウンロードする瞬間にプログラムが動かなくても許容されるじゃないですか。何ギガもダウンロードされることも多々あるよね。だから手元にruby.wasmが落ちてくるのを全然待てると思うので、最初に巨大なruby.wasmを持ってきておいて、手元で動くネイティブアプリがあると、かっこいいかもしれないと思って。なので、そういうネイティブアプリを作るときにWasmを使って、ちょっと便利になることって考えられるのかなと、ぱっと思ったんですけど。あり得ますかね？

kateinoigakukun：あり得ると思います。SwiftのWasmの話になってしまうんですけど、例えばWasmにしてウェブで動かすだけじゃなくて、それをAndroidに移植して、Androidのネイティブアプリとして、そのネイティブアプリの上で、Wasmでコアのロジックを共有するような、ネイティブの上で動かすっていうのは割とあるかなと思います。

あとは面白いユースケースかなと思っているのは、CLIでRubyファイルをパッキングして、1個のエグゼキュータブルにすることもあるかなと思います。それをWasmを介さずに、ネイティブでパッキングしたいという気持ちもわかるんですけど、それはちょっとあきらめたので（笑）。ネイティブ向けで.rbファイルをパッキングする技術としては、ruby-packerがあったと思うんですけど、ああいうのをやろうとすると、システムコールをフックするんじゃなくて、libcをバーチャライゼーションするんですね。そうするとすごく大変なんです。なので、ちょっとやる気にならかったんですけど、そっちの方向性としては、やればできるけど、すごく頑張らないといけない。ただWasmでできる範囲としては、お手軽だけど、Wasmが1枚挟まる分、非効率になる感じですね。

shyouhei：さっきFirefoxの話もあったけど、Wasmが表現できているから、ある程度そこで担保されて、安心みたいな話もあるとは思うし。

kateinoigakukun：そうですね。これはいいところでも、悪いところでもあるけど、外部にアクセスできない、外部のファイルシステムに明示されない限り、アクセスできないとか、ネットワークが使えないとかですね。そういうところが保証されるので、面白いですね。

shyouhei：ありがとうございます。いろんな応用が考えられて、すごい楽しいなって思いました。ありがとうございます。

fujimura：じゃあ、最後に、あと3分半ほどあるので、お答えしようと思うんですけど、

「addEventListenerをRuby Wasmで使うと、event.currentTarget.valueなどが参照できなくて困った。」これは気になりますね。

kateinoigakukun：それはちょっとissueを…

一同：（笑）

fujimura：たしかに、issueをよろしくお願いします。

kateinoigakukun：これは大変よろしくないやつだと思うので（笑）、

fujimura：取りたいですね。event.currentTarget。

kateinoigakukun：よろしくお願いします。ruby.wasmのリポジトリには、壊れているところがいっぱいあると思うので、コントリビューションをぜひぜひよろしくお願いいたします。

クロージング「本当に面白かった」

fujimura：まだまだ聞いてみたいこともあるのですが、お時間があと2分半とかになったので、そろそろクロージングにしようと思いますので、ちょっとモデレーターからコメントをもらおうかなと思うので、卜部さんからお願いします。

shyouhei：思っていたよりも、すごく楽しい話がいろいろと聞けてすごくよかったですね。モチベーションだったりもあるし、今後の展開だったりも、次につながっていくような面白い話をよく聞けて、よかったです。ありがとうございました。

kateinoigakukun：ありがとうございました。

shyouhei：なので、引き続き頑張ってほしいし、今からissueが登録されるらしいので。ぜひぜひ、引き続きよろしくお願いしますって感じですね。ありがとうございます。

hogelog：本当に面白かったなっていう感想なんですけども、それでいて、かつRubyKaigiで話を聞いたより、さらに広がった話や今後の話、笹田さんの話をちょっと誤解して聞いていた部分は、正しく、そういうことだったかって思ったりとか。自分たちで言うのもあれなんですけど、意外と深掘りできてよかったです。

fujimura：僕も楽しかったっていうのが、とにかく感想に尽きると思ってまして。同じことしか言えないな。広がったなっていうこと、これ聞いてみたかったんだよなってことを出してみるといっぱいあったので、そういうとこたくさん聞けたのでよかったです。恐らくWasm、コンカレンシー、パラレリズムに対して、参加する前よりも知識が厚くなったところはあるんじゃないかなと思っていて、その点でも、僕はとても楽しい会でした。ありがとうございました。ということで、kateiさんから何か一言いただけますでしょうか。

kateinoigakukun：すごい深掘ったところまでご質問いただいてたので、僕も話したいことがいっぱい話せたので、すごい楽しい会でした。ありがとうございました。

fujimura：ありがとうございました。じゃあ、笹田さん、一言いただけますでしょうか。

ko1：私もいろいろと、RubyKaigiの発表30分だとなかなか言えないことが紹介できたと思うので、いい機会をいただきました。ありがとうございます。

fujimura：ありがとうございました。（完）

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

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