RubyKaigi2025に参加した

2025-05-01

RubyKaigi2025に参加した

Ruby を書いて5-6年くらい経ちますが、RubyKaigi には参加したことがありませんでした。

今回初めて RubyKaigi に参加でき、いろんな人との出会いや会話、セッションを通じて、RubyKaigi の雰囲気を十分に味わうことができました。

参加までにやったこと

1. 事前勉強会に参加

RubyKaigi 何も分からない勢なので、事前勉強会で少しでも雰囲気を掴もうと思って参加しました。 SmartHR さんの事前勉強会、Asakusa.rb x Coincheck さんや STORESさんのタイムテーブル解説イベントに参加しました。

RubyKaigi の楽しみ方を聞いて回っていた気がします。

「発表の内容はほぼ分からないが、分からないことを楽しむ」「セッションは前の方で聴く」「登壇者に話しかける」という3つが印象に残りました。すべて実行してみたのですが、雰囲気が掴めたように思います。

2. RubyKaigi2024のセッションを見る

こちらはセッションの進み方を把握したくて見てみました。もちろん全部は見られなかったのですが、とりあえず Day1 の Large Hall のセッション内容を覗きました。確かに何もわからないという感想でしたが、知識の index は貼れたように思います。

3. やんちゃハウスに宿泊申し込み

初参加を120%楽しむためにやんちゃハウスに宿泊を申し込みました。結果として、やんちゃハウスに宿泊して良かったなと思っています。

いろんな方と交流ができた上、会話の中で新しい知識を得られたのは一番の収穫だったなと思います。カンファレンスで大事なのは廊下だという話がありますが、とても有意義な廊下の時間を得られたように思います。

複数人がいる空間で自分は寝られるのかなと不安でしたが、普通に寝られたので杞憂でした。

印象に残ったセッション

Introducing Type Guard to Steep

普段の業務でrbs-inlineを介して型を書いている身としては気になる内容でした。

以前はSteepでActiveSupport#present?の Type Narrowing がされなかったので少し不便だなと思っていましたが、すでにパッチが取り込まれていたことを本セッションで知りました。 User-defined Type Guardはとても便利ですね。ユーザーが定義した型で Narrowing ができるようになると、型安全な表現力が高まりそうです。

Conditional Typesでも利用できるとのことで、より一層、型の表現力が豊かになりそうで楽しみです。普段の開発で型をどう書いていこうかと意識を向けるきっかけになりました。

Performance Bugs and Low-level Ruby Observability APIs

会社のテックブログで書いたので詳細は省きますが、Ruby はこんなに Observability API が生えていたんだと驚きました。

lowlevel-toolkit を読むぞ！という機運が高まっています。 https://github.com/ivoanjo/lowlevel-toolkit

Ivo に対面で感謝を伝えられて写真を撮ってもらったのも良い経験になりました。（登壇者に英語で話しかけるというミッションをクリア！）

ZJIT: Building a Next Generation Ruby JIT

こちらも会社のテックブログで書いたので詳細は省きますが、やはり「Rubyの次の20年を見据えたコンパイラ」というワードが印象深かったですね。

「Rubyは良い言語だけど、もし速度が遅ければ、パフォーマンス最適化要求の波に飲まれていずれ滅ぶ」という発言がありました。

私は、ビジネスが発展するほどアプリケーションの速度要求は高まると考えていて、上記の主張に対しては同意する部分は多いなと思っています。

ZJIT は SSA に基づく中間表現を採用しているみたいです。 SSA とは「すべての変数の使用に対して、その値を定義（代入）している場所がプログラム上で1箇所しかないように変数の名前を付け替えた中間表現形式」みたいですが、何も分からないとなりました。コンパイラ Deep Dive の機運。

Modular Garbage Collectors in Ruby

Ruby の現在の GC である Mark-Sweep-Compact アルゴリズムを採用しています。オブジェクトのマーキング、不要なオブジェクトの回収、コンパクションの3フェーズですね。

Ruby の GC は主にシングルスレッドで動作するようで、マルチコア環境の利点を活かせていないみたいです。特に Ractor を使用する際にはボトルネックとなるとのこと。 Reference Counting や Semi-Space のような他のアルゴリズムは、現在の Ruby VM の設計上の制約から導入が困難だそうです。

そこで、GC アルゴリズムの柔軟性と性能を向上させるために、Ruby 3.4で実験機能として Modular GC が導入されました。何やら GC の実装を Ruby のコアから分離し、外部ライブラリとしてロード可能にするみたいですね。これによって、様々な GC 実装を切り替えることができます。

Modular GC の具体的な活用例としては、MMTk との統合があるみたいです。 MMTk は Rust で開発された言語非依存の GC FW です。 https://www.mmtk.io/ mmtk-core を覗いてみようかな。

セッションの中で、GC のアルゴリズムは長い間変わっていないと言っていた（Variable Width Allocationなどの最適化などはある）ので、変化していく様が楽しみです。

Matz Keynote

「リバースアルファシンドローム」 AI に隷属してしまうのは楽しくないし、プログラミングの楽しさを失ってしまうよねと。とても分かると思いながら聞いていました。

とはいえ、ビジネス的には進捗を求められるのでAIに頼る場面も多くなってきているなと。ただ、Production レベルのコードを書かせても、結局人間の判断軸で取捨選択できている状況だなと感じます。

将来的に AI の出力精度が上がってくると話は違ってくるかもしれない。しかし、プログラムの設計、実装は楽しいんですよね。この楽しさを維持しながらAIをうまく使いこなしていきたいなと思うわけです。

あと、Matz の Keynote で「コミッターとオーディエンスの距離は実はそんなにない」「自分のやりたいことが見つかれば、簡単にこっち側になれる」と話されていましたね。 Ruby コミュニティに関わって何かしら貢献したい。

過ごし方

基本的には Drink Up に参加して道後温泉に入るサイクルを繰り返していました。道後温泉は別館を含めて一通り制覇しました。（2階は訪れていない）道後温泉の館内入場にかかる料金形態や設備詳細まで覚えているので、道後温泉に詳しくなりましたね。

朝風呂にも行っていたので、3-4日は毎日温泉に入っていました。朝風呂後に近くのカフェに行ってまったりしてから会場に向かっていました。

あと、MusicMixin 参加して音を楽しみました。行こうとしたらすでに入場制限がかかっていて、少し時間を置いてから向かったことを覚えています。

RubyKaigi 後は姪っ子たちと愛媛観光。松山城の天守、本当に高いところにあるんだなと。

愛媛を一望できました。城外の花が綺麗に咲いていたことを覚えています。

終わりに

初参加で目一杯楽しめたので、参加して良かったなと。

同時に Ruby をもっと知りたいという気持ちの高まりを感じましたね。

来年は函館らしい。まだ北海道に行ったことがない民です。いくぞ函館。