RubyKaigi2025 セッションレポート(Day3)

はじめに

RubyKaigi2025に参加しました。

引き続きDay3に参加したセッションのレポートです。
認識漏れなどがあるかもしれませんがご容赦ください¹

またDay1、Day2のレポートもございますので合わせてお願いします

参加したセッション

Ruby Committers and the World

Rubyコミッターによる座談会

• static barrierについてどう思う？
  • RubyConf 2020で構想が紹介された機能
  • コードの途中で変数をfreezeする機能
• namespaceに対する率直な意見
• Ruby4.0に上げる場合deprecateしたい機能
• 後方互換性を無視してでも変えたい機能
• AIを使ってRuby処理系のコードを書こうとしたことはある？
• SHARABLE_MIDDLE_SUBSTRINGをデフォルトに組み込む価値はあるか？
  • ※string.cでoptionalになっている機能らしい？

Running ruby.wasm on Pure Ruby Wasm Runtime

• PureRubyによるwasm実装「Wardite」を作ってみた
  • https://github.com/udzura/wardite
• Rustによるwasm実装を参考にした
• 画像のグレースケール化するサンプルを作成した時に苦戦した点
  • メモリ確保が意図通り動作しない
  • rustのエラーハンドリング挙動がrubyと異なる
• パフォーマンスが悪くなっているのが今後の課題

Analyzing Ruby Code in IRB

• irbでのコード解析の精度を向上させる案を考えた話
• irbでの機能
  • シンタックスハイライト、ブロック内の表記、オートインデントなど
  • →これらは概ね問題なく動作するか、いくつかのエッジケースで意図通りの挙動にならないものもある
• 現在コード解析に使われているRipper::Lexerに加えてPrism.parse_lexによるパース処理と併用することで改善できないか？
  • Tokenによる構文解析だけでなく、構文木によるコード解析を行うようにする
• 現在対応中

On-the-fly Suggestions of Rewriting Method Deprecations

• ライブラリでDeprecation Warningが出るメソッドについて自動的に修正する仕組みを考えた話
• 現状の場合は以下の3パターン
  • YARDなどのコメントとしてdepricatedであることを記述
  • 対象メソッド実行にwarnログを出力する
  • rubocopなどで指摘されるようにする
• 他言語でも概ね上記通りであるがpharoという言語では別の仕組みがある
  • プログラム実行時に対象メソッドを呼び出す場合、自動的にコードを書き換える
  • →これをRubyにも適用させてみた
• Deprewriter in Ruby
  • https://scrapbox.io/ohbarye/Deprewriter_in_Ruby
  • クラス定義部分に置き換えルールを記述して、テスト実行時にそのルールに沿って該当メソッドを置き換える
• 課題
  • テスト時にコードを書き換える処理が安全ではない
    • 安全な実行モードを追加
      • log mode・・・warningのログを出すだけ
      • diff mode・・・patchファイルを吐き出す
  • ライブラリ開発者に置き換えルールを記述してもらうのが負担になる
    • ライブラリを使う側がモンキーパッチを当てる形で記述することになりそう
  • コードの修正処理が効率的でない
    • すでに修正済みのコードであっても舐める挙動であるため
  • 実装が他のgemに依存している

Matz Keynote(Programming language for AI age)

• セッションでAIに関する話がなかった（らしい）のでその辺の話
  • なお「Programming language for AI」だとpythonでいいじゃん、ってなる模様
• AIによってプログラマの仕事がなくなるんじゃないか、という話があるがそうはならないはず
  • おそらくAIが苦手とする分野は人間が引き続き対応することになるはず
    • 要件から仕様を決める部分とか
  • 上記のような大抵楽しくないことをやらざるを得なくなる状態になるのはAIに使われているようなものでは？
    • 「reverse alpha syndrome」
    • それは「楽しくプログラミングする」というRubyの在り方からもはずれてしまう
• AIが発展するにあたりどのような言語が望ましいか？（自然言語も含めて）
  • 記述が簡潔、多様な表現力、拡張性がある
  • →それってRubyだよね？（予定調和）
• これから必要なもの
  • データ
    • AIに食わせる学習データとしてはモダンかつ質の良いコードが必要になる
  • ツール
    • 開発を補助するツール
    • Rubocop、Steepなど...
  • パフォーマンス
    • やっぱり速いほうがいいよね
• まだまだやれることはある
  • Rubyは今の段階では他言語に勝てない部分もあるがのちのちは・・・？
  • 今のコミッターだけでなく一人一人が参画してくれればRubyはもっと良くできるはず

余談

• Rubyは今年でリリース30周年
  • 初期版(v0.95)のリリースが1995年
• 今年のクリスマスはRuby4.0をリリースする（・・・予定）
  • 下記機能が試験的に導入される予定
    • namespace
    • ZJIT

次回RubyKaigi2026は函館で開催！

2026/04/22 〜 2026/04/24

おわりに

自分自身が大変シャイであったこともあり今までこのような場を避けていましたが、これほどたくさんのエンジニアの方々とお話することができたことは大変良い刺激となりました。
語弊を招く言い方になるかもしれませんが、Rubyコミッターが直に会えることも「Rubyのコミュニティが(良い意味で)狭いコミュニティなんだな」ということを強く実感できました。

来年は他のエンジニアと一緒に行きたいなー(願望)

1. 英語のセッションがあまり聞き取れなかったので特に認識漏れあるかも ↩