はじめに
しばらく Ruby から離れていた私にとって、Matz さんのキーノートはここ数年の Ruby のふりかえりにもなり、とても良い内容でした。
まだスライドは公開されていない(はず)なのでメモベースですが、私なりにまとめさせていただきました。
まとめ
今日の内容は Ruby をより良くする話で、テクニカルトークではない。
Ruby をより良くするためには、以下の 4 つの側面がある。
- パフォーマンス
- パフォーマンス
- パフォーマンス
- パフォーマンス
１つ目のパフォーマンス: VM
- YARV (2007)
- Bytecode VM
- MJIT (2018)
- Ruby3x3 (2014)
- Rails App ではあまりパフォーマンスが変わらず、メモリ消費量は増えた
- YJIT (2022)
２つ目のパフォーマンス: メモリ管理
３つ目のパフォーマンス: マルチコアの活用
- マルチコア時代は想像できなかった
- パフォーマンスを向上させるためのスレッドではなかった
- どちらかというと、プロデューサー/コンシューマーモデルとか
- スレッドをいっぱい作ってもパフォーマンスは全然改善しない
- Threads
- GVL
- Global VM Lock
- 1度に1つのスレッド
- Processes
- プロセスは生成コストと切替コストが高い
- Fiber (for I/O)
- マルチコア使えない
- Actors (for CPU)
- まだ本番では使えない（Matz 視点）
- 今後
- NxM Threads
- Lightweight Ractors
- 1 Ractor 1スレッド
- Ractor local GC
- Fiber Scheduler
４つ目のパフォーマンス: 開発者
- 開発者のパフォーマンスも大切
- Ruby-LSP
- Rubocop
- Steep
- Copilot
The state of Ruby dev tooling聴きたかった- より良いパーサーが必要
- parser gem
- ripper
- ruby コマンドとそれ以外のツールで使っているパーサーが違った
- 1つのパーサーが必要
- 一昨年、パーサー時代が始まった
- Prism
- Hand-written Parser
- Parser by Lrama
- Parser from Parser Generator
- 最新の parser gem は Prism に依存するようになっている
- Prism のインターフェースに依存しようと思っている
- シンタックス・モラトリアムを提案したい
- 最短で今年いっぱいで、文法の変更をしない
- それぞれのパーサーが同時に実装をしないといけない
- パーサーの改善に集中してほしい
- バグフィックスなどは行う
その他
Namespace, What and Whyというセッション- Namespace, What and Why - RubyKaigi 2024
- Ruby2(2004) という構想があった
- リスタートしようとトライした
- Perl6 や Python3000 もあった
- Perl6 は使われなかった
- Python 3000 → Python3.0 になったが、コミュニティが分断された
- Ruby 4.0
Namespace, What and Whyがはいったら、Ruby 4.0 にしても良いと思っている
- 実現できるかわからない夢
- 最近、ヨーロッパでは Ruby のカンファレンスが増えてきている
おわりに
私個人の RubyKaigi 2024 感想については、以下のブログ記事をご覧ください〜。
