Day 3
Ruby Committers and the World
shopifyさんは35人エンジニアがいて 8人がインフラ（？）チームで 4人がコミッターだそうです。 エンジニア数の少なさにびっくりします。 自社が40人くらいなことと比較して考えると、レバレッジがすごいです。 やはり、ビジネスが大きくなるかの鍵はエンジニアの人数ではなさそうです。
frozen literal
frozen literalが4.0でデフォルトに、 3.4.0からは警告が出るようになるそうです。
仕事でRuby on Ralisアプリケーションを書いている人は、 rubocopでfrozen literalのマジックコメントに警告だしている現場も多そうです。 すごい大きい影響はでないのかな？
mametter さんは色々思いがあるようでした。
ビルドシステム
ビルドシステムが大変という話が出ました。
parse.yに色々手を入れる人が出てきて整備され始めました。 次のRubyの魔境はビルドシステムなのかもしれません。 kateinoigakukunさんビルドまわり強いですよね。 ruby.wasmのビルドもめっちゃ作り込まれています。
GVL
GVLの話が出ました。 PythonがGVL(GIL)を取ろうとしているので意識はしますよね。
GVLをとるとRubyが内部的にロックをとる場所が増えて、シングルスレッドでは遅くなるそうです。
また、スレッド間で衝突する場所が多いとそれほど速くならないそうです。
_ko1さんは、Ractorのために衝突を見つけては減らす、地道な作業をしているそうです。
並行処理はGVLがあればThreadで十分です。 1万スレッドとか立てたければFiberを使う手もあります。 GVLを外して恩恵をうけるのは並列処理です。 しかし、Ractorの事例があんまり出てこないところをみるに、世の中にそんなに並列処理したい需要はあるのでしょうか？ そんなにというのは「シングルスレッドの性能を落としてまで、並列処理したいですか？」です。
そんなに並列処理への情熱があるなら、Ractor使えば良いんじゃないのかあ？ GVL外したからってRactorより性能がでるわけじゃないんですよ。 既存処理をRactor readyに書き直すのが大変なのはわかるけど、 GVL外したら全部がそうなるんだけなんですよね。
async/await
async/awaitの話が出ました。
「async/awaitを使うとソースコードの見た目がわるくなる」のは、そうなんです。 「ほとんどの関数を非同期で呼んで、時々同期で呼ぶ」ときはバッチリです。 ただ、多くの場合は全部の関数を同期で呼びたいです。 すべての関数呼び出しの前に機械的にawaitが並びます。 ノイジーです。
「auto fiber を使えば、非同期にできるものが自動的に非同期できるので便利」もそうですよね。 実際に、使ったことはないので、感触まではわかっていません。
「関数を書くときにasyncか最初からわかるの？」という問いもわかります。 ブラウザではfetch APIとか外部リソースを呼ぶときは、APIがasync関数になったので、わかりやすいです。 サーバーサイドだと、 asyncを使うか予測するのは、難しい気もします。 しかも、Rubyのサーバーサイドプログラミングを書くときって、ほとんどの人は同期の世界でプログラミングしてますよね？ Node.jsのときはイベントループのイベントハンドラーを実装する気分で書いているから、わかるんですよ。
同期的なプログラミングを書くC#でもasync/awaitが結構上手く行っているので、C#を参考にした方がいいのかもしれません。 C#ではたくさんのasync/awat書いたことがありません。 JavaScriptでもテストコードでは書きますが、プロダクトコードではたくさんは書いていません。 外部リソースをつかうときはわかりやすいのですが、ブラウザ内で動くロジックで非同期関数をつかうと、どうしても同期のタイミングを制御する仕組みを作り込む必要があります。 そこが面倒なのでなるべく速く動く同期関数を書いてしのいでいます。 C#のasync/awaitには「時間の掛かる処理をTaskを返す関数で書いて、awaitつけて呼ぶと勝手にスレッドつかって実行して、終わったらメインスレッドに同期する」仕組みが.NET Frameworkに組み込まれているので、そこまで作り込むと使い勝手が良いのかもしれません。 まあ、こういう仕組みが入ってくるとRubyっぽくないなって感じはします。 Railsのようなフレームワークがやるのはありです。 load_asyncが既にあることを考えると、そのサポートに必要なのはasync/awaitではなさそうです。
この話題では、Promiseが入る前にJavaScriptコミュニティーの強い人が言っていた「コールバックヘルになるのは設計が悪いのであって記法は関係ない」という主張を思い出します。 async/awaitも似たような点がありそうです。 async/awaitで解決したいことって本当は記法の話ではないようにおもいます。 C#には「画面が固まらないWindowsデスクトップアプリケーションを増やしたい」みたいなモチベーションがあったように思います。 いまのところRubyはサーバーサイドプログラミングが主戦場で、GUIやブラウザで動かすシチュエーションが少ないです。 ruby.wasmをつかって、inブラウザプログラミングが増えたら、何かあるんですかねえ？ いまのところはkateinoigakukunさんが作ってくれた、Fiberベースのスケジューラーとawaitメソッドで何も困らないんですよねえ。 Promise.allとかはライブラリーで吸収できそうです。
というわけで、僕は「今のところは要らない派ですが、ruby.wasm関連で欲しくなるかもしれないから気になるなあ」というステータスです。
Turning CDN edge into a Rack web server with ruby.wasm
remore さんの、CDNのエッジワーカーでrackを動かす話です。
FastlyではCDNのエッジをpopて呼ぶそうです。 いい名前ですね。すごくそれっぽいです。
いまのところレスポンスに1000msかかって辛いそうです。 アプリケーションなら起動に一秒かかってもいいですが、 CDNだとレスポンスが重要なので厳しいですよね。
あとで質問したところ、なぜrackが遅いのかはわかっていないそうです。 wasm用のプロファイラがなくて、遅い原因を特定するのが難しいそうです。
途中、C言語の関数を実装してたところが追えませんでした。 これも質問したところ、エージワーカーで、つまりWasmの外側で動く関数を実装したそうです。 witの何かのツールつかってバインドしてたそうです。
起動を速くする手法として、起動後のバイナリをWebAssemblyに焼き込んでおく方法があるらしく、それを試してみたいと聞きました。 あとで、何かの記事で見たのを思い出しました。 WebAssemblyで、JITコンパイラに迫る高速なJavaScriptエンジンを実装へ。Bytecode Allianceが技術解説。JavaScript以外の言語でも － Publickeyに載っているWizerってやつかなあ？
あと、エッジワーカーの事例として「リクエスト元に応じて異なるQRコードを返す」を聞けて良かったです。
lunch
なはーとの向かいのブリトー屋さん MILCOMIDAS （ミルコミダス） - 美栄橋/メキシコ料理 | 食べログ でテイクアウトして、緑ヶ丘公園で食べました。
よく知らなかったのですが、ブリトーにはお米が入っています。 メキシコ風タコスおにぎりみたいな感じです。
そして、自分の発表に向けて最後の練習をしました。
Speeding up Instance Variables with Red-Black Trees
tenderlove さんの発表。
発表の構成がうまいですよ。 僕なら「ObjectShapeは削除されないから、キャッシュにつかうなら進研ゼミでやった赤黒木がぴったりだとおもう。やってみたら本当にぴったりだったよ」というなんの盛り上がりもない話をしそうです。 次のエピソードを入れてくるところが良かったです。
赤黒木っで実装難しいじゃん。 でも、Articles/Haskell/Purely Functional Data Structures (Okasaki).pdf at master · aistrate/Articles · GitHubとRubyのパターンマッチを使えば！ ほらね！
アルゴリズムの勉強にもなるし、パターンマッチの使い所の紹介にもなるし、聞いてて得した感じがしました。 そこから「ObjectShapeのキャッシュに赤黒木を使う」完璧な対応を見せてくるところが、またテクくてよかったです。
ERB, ancient and future
ERBはruby.wasmでもつかえて便利なんですよ。 この発表のように「ERBはCGI以外にもつかえるはず」ってアイデアがあったからなんですよね。 また、テンプレートのなかで別のテンプレート呼べるのもbindingを渡せる設計にしてくれたからです。
ていうのを、25年前に25年以上つかえるように設計して、バチッと決めるのなんなんでしょうね？ オーパーツ？
Using Ruby in the browser is wonderful.
このあとのセッションはお休みにして、自分の発表の準備をしました。
Matz Keynote
パフォーマンスについて何度も言及していたことが印象的でした。 また「namespaceが入ったらRuby 4.0にする」もインパクトのある発言でした。 僕の中では、無根拠にnamespaceがproduction readyになるには3年、あるいは5年くらい掛かる予感がしています。 すると、Ruby 4.0はそれぐらいかなあ？と思いました。
Closing
RubyKaigiはたくさんのスタッフの方達に支えられています。 ありがたいことです。
帰路
day 1からday 3まで、3日間、お天気に恵まれて良かったです。
dinner
沖縄に来たからには、A&Wを食べて帰らなくてはいけません。
