2018-06-01 - メモるブログ

RubyKaigi 2日目。今日も超絶楽しかった

Rubyでパラレル処理する機構の話
- GuildはGVLの挙動を変える変更（という理解）。マルチスレッドでもマルチコアを活かせるようになる。
  - 今まで: Process -> Thread -> Fiber
  - これから：Process -> Guild -> Thread -> Fiber
- Guildというのはプロジェクト名なので実際の名前は検討中らしい
- Actorモデル（スレッドとか意識せずにモデルレベルでメッセージパッシングしていく感じ）
所感
- マルチコアを使い切りたいというのは数値計算をマルチコアでスケールさせたいという感じの要件から来てるのかなーと思った。webのコンテキストだと、現状でもコンカレントに動いてIOバウンドな処理に対しては実用上問題ないレベルでスケールする気がするし、pumaとかはマルチプロセス・マルチスレッドで動くのでサーバーリソースは今のRubyの仕様でも十分使い切れる気がするので、Guildが入ったからと言ってwebのパフォーマンスが改善させるとかそういう話ではないと思う。
- GVLのロックをかけずにセキュアにマルチコアでスレッドを動かす感じだと思うが（そのためにmutable/imutableなオブジェクトの扱いや共有するか否かのあれこれが必要）、GCの扱いが結構変わりそうだしRubyに入るのはもう少し後になりそうだなーと思った

steepの話
- https://github.com/soutaro/steep
sorbetとは違うアプローチで、外部ファイルに型情報を定義して、実ファイル内にアノテーションを書く、というスタイルでの型チェック。sorbetは実ファイルにsignature（＝コード。コメントではない）を書くスタイル
型情報定義面倒そうだなーと思ったけどscaffold的な型定義ジェネレータなコマンドがある（全部、型がanyになるけど…）

ASTのノードの構造体であるRNodeにコードポジション（行とか列とか）を付与したので色々できるようになったよ、という話
NoMethodErrorでこういう表記ができるようになる（barが無い場合）。ASTのノードにコードポジション付与して、ASCIIでグラフィカルに良い感じに表示ってpower-assertっぽいなーと思った

foo.bar
   ^^^^

型チェックのアプローチの話
1番目: メソッド内で対象の引数に対してAメソッドが呼ばれていたら、対象の引数はAメソッドを持つ引数だ！という感じで引数を推測する方式
2番目: メソッド内で a = b + 1という式があったら、B#+(NUM) 戻り値A、となるようなメソッドを持つクラスを探してBとAの型を推定する方式
3番目: IntelliJがRubyTypeInferenceというのを進めている。テスト回してメソッドに与えられた引数のクラスとかを見て、メソッドの引数の型を推測する方式。
TypeDB
- 型定義情報を定義するDB。型チェックはいろんなアプローチがあるが、TypeDB経由で3rd partyの型チェッカを動かせるようにできるように、という構想。例えばTypeDBを使ってsteepの型情報ファイルを生成したり、IDEに型情報をフィードバックして精度上げたり