はじめに
こんにちは、terandard です。
先日 RubyKaigi 2024 に参加してきました。
RubyKaigi 2023 が初参加だったので 2 年連続の参加となります。
Social PLUS からの参加者は自分を含め simomu, okumud の 3 人です。
この記事ではそれぞれ印象に残ったセッションについて紹介していきます。
印象に残ったセッション
Writing Weird Code
writer: okumud
TRICK 2022 で金賞を取ったコードの解説や、Self TRICK での Ruby の柔軟性と性能を示してくださいました。
国際通り等で RubyKaigi の広告があったそうですが、それも Ruby コードで出力された動画だったそうです 👏
技巧コード(奇妙なコード+文字コード)から、WASM、マルチスレッドでの処理(Ractor)や、その性能調査(profiler)まで盛り込まれている内容でした。
画像に埋め込んだ Ruby コードを実行できる等、「すごい」以外の言葉が出てきませんでした。
Namespace, What and Why
writer: okumud
Namespace "on read" の実装(ライブラリを使う側が、ロード時に設定する方針)を進めているという発表でした。
実装は Namespace を Module のサブクラスとして実装し、既存の load(file, module) を使って読み込んでいるとのこと。
ネイティブライブラリもサポートしていますが、ロードの方法を工夫しないと読み込めない(dlopen は複数回できない)ため、
裏側で .so ファイル等をコピーして、別のライブラリとしてロードするようです。
Namespace により、どんなことが実現できるかの紹介がありました。
- Modular-Monolith Deployment
- 1 プロセスで複数のアプリケーションを動かす(主に開発用)
- Dependency Hell の解消
- ライブラリ間の依存関係で古いライブラリを使えるようにする
- "Packages" API の実装
- 名前空間を Export して、呼び出せるようにする
私の経験では、プロセスが動いていると生成したライブラリを削除できないなど、動的ライブラリ読み込みの後始末が非常に大変だったので、すごいことをやろうとしているなと感じました。
提案段階のようですが、古いライブラリの依存関係の解消や、パッチの分離等で使えそうだと思いました。
Embedding it into Ruby code
writer: simomu
RBS の型定義を Ruby コードに埋め込むことができる「RBS inline」というツールについての発表でした。
もともと RBS は実装とは別のファイル .rbs に型定義を書くというものだったのですが、これは保守が大変だよねということで実装側にコメントとして RBS の型定義をコメントに書いておいて、そこから .rbs を生成できるようにするツールを作っているとのことです。
Ruby のコード内に型定義を埋め込むのは既に Sorbet でも行われていますが、Sorbet はあくまで Ruby コードとして型定義を行う一方で、RBS inline はコメントとして記述するため、
RBS の定義の書き方に近い印象でした。
以下のような感じだそうです。
# rbs_inline: enabled
class Person
attr_reader :name #:: String
attr_reader :addresses #:: Array[String]
# @rbs name: String
# @rbs addresses: Array[String]
# @rbs returns void
def initialize(name:, addresses:)
@name = name
@addresses = addresses
end
def to_s #:: String
"Person(name = #{name}, addresses = #{addresses.join(", ")})"
end
# @rbs yields (String) -> void
def each_address(&block) #:: void
addresses.each(&block)
end
end
上記の様に YARD のような Document 形式の記法から、簡易的な記法も用意されているとのことです。
RBS inline はまだ実験段階で、syntax もまだ模索中の段階だそうで、3日目の「Ruby Committers and the World」でも syntax に関してのアンケートがありました。
もともと RBS が出てきた当初から実装と型定義が別のファイルになっているのは保守が大変そうだなという感想を持っていました。
例えば YARD のようなコメントで書くことができれば良いなと思っていたので、これはまさに自分が欲しかったものという感じでした。
YJIT Makes Rails 1.7x Faster
writer: terandard
YJIT を無効化している状態と比較して Ruby 3.4dev では既に 1.79x 高速化しているそうです 🎉
Matz のキーノートでも話されていましたが、パフォーマンスが上がるとワクワクしますね 😊
印象に残った理由として一番大きかったのは、発表の中に自分の記事が出てきたからです 😳
現在 Social PLUS では Ruby 3.2, Rails 7.1 で YJIT を有効にしているので、Ruby 3.3 に上げたらまた記事を書こうと思います。
高速化だけでなく、メモリ使用量の話も出ていました。
省メモリで動作させる工夫について話されていましたが、Ruby 3.3 に上げる際に直接関わってきそうなこととして --yjit-exec-mem-size が気になりました。
デフォルトでは 48MB に設定されていますが、実際のところ YJIT はそれの 3~4 倍使用するそうです。
Ruby 3.3 に上げる際は速度だけでなくメモリ使用量に関しても注視しておきます。
所感
RubyKaigi を通して知らなかったこと / 分からないことを知ることができ、例えば Tech Racho の Ruby / Rails関連記事で「これに関するセッションを見たな」や「あのセッションで何も分からなかったけど、キーワードがあるし読んでみるか」など普段の勉強のモチベーションにも繋がっています。
普段の小さな勉強の積み重ねのおかげで昨年と比較して理解できたセッションが増えており、成長を感じることができました。分からなかったセッションもありましたが、scrapbox に他の方の参加レポートなどがまとまっていたので目を通しておこうと思います。
Discussion