#RubyKaigi 2024 セッションレポート - メドピア開発者ブログ

サーバーサイドエンジニアの内藤(@naitoh) です。

RubyKaigi 2024に参加されていた皆さん、お疲れ様でした。 RubyKaigi のセッションの中で印象に残った発表をご紹介します。

タイムテーブル

タイムテーブルは以下から確認できます。

rubykaigi.org

Namespace, What and Why

今回のRubyKaigi で非常に気になっていたセッションの一つです。

アプリケーション、ライブラリをある空間の中でライブラリを読み込み、他の空間から隠す。
空間の中で定義されたメソッドを別空間から呼び出すこと
別空間から呼び出されたメソッドは、元の空間内で動作すること

という感じで複数のバージョンのライブラリに依存した場合のコンフリクト発生を解決するのが Namespace とのことで、内容が整理されておりわかりやすかったです。

Namespace "on read" ということで、 既存の gem をそのまま使いたい が特徴で、"on write" だと、Namespace を使うときに宣言して使うアプローチ(例: 別言語, python)になり、これだと既存の gem の対応が必要になるので、なるほどと思いました。

Namespace があると 1つの Ruby プロセス上で、複数のアプリケーションサーバーを動かすことが可能になり、コンテナレスで開発環境を構築するのが容易になりそうとのことで、柔軟性高いなーと感じました。

speakerdeck.com

The FAQ about "Namespace on read"
Namespace on readについて #rubykaigi 中によくもらった質問などをまとめたFAQを作りました
---
"Namespace on read" for Ruby, FAQ https://t.co/pVKDeCTJxw
— tagomoris (@tagomoris) 2024年5月20日

It's about time to pack Ruby and Ruby scripts in one binary

実行ファイル一つで実行できるOne Binary 形式の話です。 Ruby の One Binary 用途として、Rubyプログラムを配布したいときが想定されており、通常の Ruby スクリプトをそのまま配布した場合、配布先のユーザーの Ruby 環境が古いなど、期待しないバージョンの環境の場合だと動作しない問題を解決できるとの事。既存の one binary ツールには下記の課題があるため、kompo gem を作ったとの事です。

Ruby 3.0 未満のサポート
Ruby にパッチが必要
Windows のみサポート
一時ファイル書き込みがある

クロスコンパイル未対応の課題はありますが、native(C拡張 gem?) にも対応してるそうなので、使い勝手が良さそうですね。

speakerdeck.com

Ruby Committers and the World

毎年楽しみにしている、Ruby Committers and the World です。

今年は下記の内容が議論されていました。

#frozen_string_literal: true をデフォルトにする話
- "" をバッファに使うケースは多いので、+"" にすれば良いのはわかるが手間が増える。
- Quine で 1文字増えるのは、それだけで厳しい。
- YJIT には効果ありそう
- Ractor は Frozen したい
- 型は他言語の静的方向の流れとは逆張りしたのに、#frozen_string_literal: true は他言語と同じ immutable の方向。

というような議論になっていました。 Ruby 3.4.0 preview1 はデフォルト有効になっているけど、引き続き議論中という流れでした。個人的には性能UPに繋がりそうなのでデフォルト有効は賛成ですが、3.4 での変更ではなく 4.0 でのメジャーアップデート時の変更だとわかりやすくていいなと思いました。

Embed RBS

YARDにも型があるぞということで、整合性をとるために YARD → RBS 変換できるといいねという話がありました。

個人的には別ファイルだと型は書かないだろうなという感じですが、メソッドのすぐ上に書けるなら型を書くのもありかなという感じです。

GNU autotools を cmake に変更したい
(Python のように)GVL を取りたい
async/await の usability の話
- async/await をいっぱい書くのは、書きにくいのでは
- 最初から、対象のメソッドに async/await が必要ってわかっていて書けているのか？
- 後から、必要になって async/await を書くのは bad 体験
Golang の defer が欲しい話
- ネストを深くなるのを回避できる
- いい文法があれば
- ensure は最後に書くことになるのが問題 (リソースを使用した直後に書きたい)

などの議論がありました。 Ruby開発者の温度感がわかって楽しかったです。

YJIT Makes Rails 1.7x Faster

YJIT みなさん使ってますか？

YJIT Makes Rails 1.7x faster / RubyKaigi 2024 - Speaker Deck で紹介されたように MedPeer でも YJIT を有効にして速くなっています。感謝！

講演では Ruby 3.3 で高速化された YJIT の高速化された手法の紹介がありました。

Method Call Fallback の仕組みでJIT できない場合、Ruby インタプリタに処理を戻していたケースのいくつかで、JIT 可能になり高速化。
スタック変数をメモリ上で処理していたのをレジスタ上で処理するようになった。
Active Support の NilClass#blank? がインライン化され 1命令になるのは圧巻でした。

という感じで、素晴らしい改善ですね。 Ruby 3.4 でも改善が進んでいるみたいなので超期待です。

speakerdeck.com

Speeding up Instance Variables with Red-Black Trees

毎回、わかりやすく説明頂ける @tenderlove さんの講演です。 ObjectShape キャッシュミス時の検索に赤黒木を使うことで、計算量を O(n) から O(log(n)) に減らしたという内容でした。

ObjectShape の各オブジェクトもツリー構造に配置されるので、赤黒木のアルゴリズムが使えるんですね。該当の PR は https://github.com/ruby/ruby/pull/8744 になると思います。

ただ、私は赤黒ツリーを理解していなかったため内容にあまりついていけず、非常に残念な思いをしました。観たいセッションの講演概要に知らないキーワードがある場合は、事前勉強が重要ですね！

コンピュータサイエンスの知識があると、最適なアルゴリズムを選択できるため知識は重要です。動画や資料が公開されたら再度確認したいです。

Lightning Talks

手前味噌ですが、LTで発表させて頂きました。詳細は、下記を参照頂ければと思いますが、LT発表すると他の方のLT内容を聞けないのが残念ですよね。こちらも動画が公開されたら確認したいです。

はてなブログに投稿しました#RubyKaigi 2024 LTで「Improved REXML XML parsing performance using StringScanner 」というタイトルで発表しました。 - @naitohの日記 https://t.co/Y8qSUgtPkX #はてなブログ
— NAITOH Jun (@naitoh) 2024年5月20日