Zenn
🏖️

RubyKaigi2024に参加してきました⛱️

2024/06/03に公開
Ruby
rubykaigi2024
tech

2024年5月15〜17の3日間、沖縄県那覇市で開催されたRubyKaigi2024に参加してきました！
今年も楽しかったですね・・・！

だいぶ間が空いてしまいましたが、聴講したトークや思ったことなど書いてみました。

トーク感想

Day1

The grand strategy of Ruby Parser by Yuichiro Kaneko

発表資料

Ruby3.3で導入されたパーサージェネレータであるLramaについて、どんなものなのか、それがなぜ選ばれたのか、そして現在のRubyのパーサ周りの開発がどのような状況かといった内容でした。
まずここでいうパーサとは、Rubyのコードを解釈してASTとして出力するためのものです。
出力されたASTは、主にLSPのような開発支援の外部ツール等で使われます。
Ruby3.3では、それまでのBisonに代わってLramaというRubyで書かれた新しいパーサージェネレータが採用されました（RubyがRubyをパースしてるってすごい）。
パーサジェネレータとはその名の通りで、文法ファイル（Rubyの場合はparse.y）からパーサを生成するものです。
手書きのパーサではなくジェネレータを使うのは、Rubyの多様な書き方に対応するにあたり人の手で全てを網羅するパーサを実装するのが困難であるからのようです。
なお、従来はバーサジェネレータとしてBisonというものが使われていたものの、Rubyのパーサーとしては機能不足かつ、機能追加したくても実行環境のBisonバージョンに依存してしまうという扱いづらさがあったために新しいパーサジェネレータが必要だったようです。

パーサの改善は、

  • LSP等からの使いやすさ
  • 保守性
  • ユニバーサルパーサの実現

の３つの観点で進められており、発表内ではそれぞれを起点としたマイルストーンが示されました。
現在金子さん以外にもパーサの改修を進めてくださっているため、マイルストーンの半分近くが完了状態となっているようです。すごい！

しかしまだ真なるユニバーサルパーサの実現など、取り組まなければならない課題はあるようです。
Ruby3.4にむけて、ユニバーサルパーサの完成、より良いエラートレラントパーサの実現、Prismインターフェースの作成といった点に対応されていくそうです！

パーサの勉強が足りず、ついていけなかったところも多いのですが、Lramaの登場により、今後外部ツールの高性能化や新しいRuby実装などが増えてくるのかなとワクワクしました。
金子さんのパーサ愛が溢れる発表でした！

Long journey of Ruby standard library by Hiroshi SHIBATA

発表資料

Rubyと一緒に配布されているライブラリの整理についてのお話でした。
Rubyには標準添付ライブラリとして一緒に配布されているgemが複数ありますが、現在はこれをStandard gemsとBundled gemsのふたつに分けて整理していっているそうです。
Standard gemsは、バージョンを指定する必要がなければgemfileに書かずとも使えるgemであり、Bundled gemsはgemfileに書くことで使えるようになるgemです。
このように分類する理由は、Rubyのアップデートをせずとも各gemのアップデートができるようにすることで、セキュリティ対応などをスピーディに行えるようにするという狙いがあるそうです。現在は標準添付ライブラリに含まれているgemをアップロードすると、自動的にRuby本体にも反映される仕組みが整備されているとのことです！

また、Standard gemsを徐々にBundled gemsに移していくというのを進めているとのことです（これが地道な作業らしく、大変そうでした・・・）。
この結果、現在そのまま使えているgemが、Rubyのバージョンアップによりgemfileに追記しないと使えなくなる場合があるとのことです。しかしそのような場合にはちゃんと警告が出るようになっており、それに従ってgemfileに追記することで解決するようです。
また、gemが間接的に呼んでいるgemがStandardからBundledに変わった場合も、どのgemから呼ばれているのかがわかるようになっているとのことで、そのような場合はぜひ呼び出し元のgemにPRを提出して、gemfileへの追記や依存の引き剥がしなどを提案して欲しいとおっしゃっていました（こういう警告見たらコントリビュートチャンスということですね！）。

また、今後の話として「Namespaceがほんとにほしい」とおっしゃってました。
現状は名前の競合等を避けるため、gem製作者の皆さんはわざわざ自前のモジュール内に依存しているgemを埋め込んだり、C拡張についてはRubyで再実装したりして対応してくださっているとのことで、Namespaceが導入されればそのあたりの問題が解消できそうとのことでした。

柴田さんだけでなく、gemを作って公開してくださっている方々にも本当に感謝しなければならないと感じるお話でした・・・！

Namespace, What and Why by Satoshi Tagomori

発表資料

Rubyの新しい機能として開発中のNamespaceについてのお話でした！
Namespaceとは、アプリケーションやライブラリを隔離された空間の中で読み込む機能で、

  • ある空間の中で読みこむことができる
  • 変更を他の空間から隠すことができる
  • 外側からその中で定義されたものを読み出せる

のように定義されていました。

現状のRubyにはこのような機能がなく、全ては単一のグローバルな空間の中に置かれています。
これにより、例えば同じライブラリの別バージョンを同時に使用することができなかったり、オープンクラスによる変更（モンキーパッチ）がコード全体に影響してしまうといった問題があります。

Namespaceは、こうした変更を開発者やシステムが定義した個別の空間内に閉じ込めることにより、衝突を回避できる機能です。
既に動くものができており、発表の中では、古いバージョンのgemを使用するアプリケーションと、新しいバージョンのgemを使用するアプリケーションを同時に実行するというデモを見せてくださいました！👏👏👏
名前空間は任意に定義することができ、現在の空間内で特に変更されていない要素は上位の空間内の定義を参照するなど、直感的にわかりやすく感じました。
また、Namespace導入にあたって既存のgemを更新せずとも済むように、on read(gem側での明示的な空間定義がなくとも、gemを読み込んだ時に自動的に専用空間が定義される)の方針にしたいとおっしゃっていました。

さらに、今後の構想として、コンテナを使わずとも一つのRubyプロセス内で複数のRubyアプリを実行する、Rubyバージョンのコンフリクトを自動解決する、パッケージAPI（個々のライブラリではなくひとまとめにしたパッケージとして読み込む機能？ちょっと理解しきれませんでした）を提供するなど、いろいろな機能に派生させることができそうとのことでした！
まだアイデア段階とのことでしたが、お話を聞いてると本当に実現できそうな気がします。

いつからNamespaceを使えるようになるかが気になるところですが、現状はプロポーザル段階で「激しく開発中」とのことだったので、具体的なスケジュールはまだなさそうです。
とはいえ既に動いているものを見せていただけたので、そう遠くはないのかなと思いました。

前の柴田さんの発表と併せて、gem開発がかなり楽になっていく素晴らしい機能と感じました！

Exploring Reline: Enhancing Command Line Usability by Mari Imaizumi

発表資料

IRBで使用されているコマンドラインエディタであるRelineの説明と、Undo機能追加についてのお話でした！
この発表におけるコマンドラインエディタとは、例えば矢印キーによるカーソル移動や履歴を表示、自動補完といった機能を提供するものです。
代表的なものとしてGNU Readlineがあり、Relineはこれと互換性を持つことを目標にRubyで実装されたシステムです。

RelineはGNU Readlineの大きな機能は網羅しており、かつダイアログ表示やマルチライン対応といった追加機能もあるのですが、細部ではまだReadlineにあってRelineにはないという機能も残っています。
その一つが、.inputrcで設定できる各種機能です。
こちらは所定の操作（入力モード切り替えやundoなど）のキーバインディングを設定したりできる機能で、Readlineでできるもののうち、半分強がRelineでは未実装とのことでした。
現在は使用頻度などの情報をもとに、優先順位をつけて機能追加を進めているとのことです。

今回の発表では、そんな追加予定の機能の一つであるUndoの実装を検討しながら、Relineのコードがどのような実装になっているかを説明してくださいました。
ざっくり言うと、あるキーを押すと、押されたキー, カーソル位置, 既に入力されている文字とその配置の情報が渡され、キーに紐づけられているメソッドが実行されると言う感じでした。
発表内ではそれらの機能を使ってC-_のキーバインディングでundoできるようにするとという修正を説明してくださいました。
既にこの修正はマージされており、実演も見せていただけました。とても便利。

今後については、undoだけだとバランスが悪いのでredoも追加したいということと、ドキュメンテーションがないので作っていきたいとのことでした。
IRBでUndoが入るのほんとに便利なのでありがたいです・・・・！
Relineのコードも読んでみたいと思いました！

Refactoring with ASTs and Pattern Matching by Brandon Weaver

Rubyのパーサが出力するASTを、Rubyのパターンマッチ機能を使って解析してリファクタリングするシステムを作るというお話でした！
Rubyの複数のパーサが出してくれるASTの比較、パターンマッチ機能の説明から始まり、それを組み合わせると、例えばあるブロックの実装を省略記法(p(&:foo))で置き換えられるかどうかなどを検出できることを、実際のコードを使いながら説明してくださいました。
具体的で愚直な実装から、徐々に抽象化して整理されていくという感じの説明で、それ自体もリファクタリングのやり方として綺麗で勉強になるなぁと感じました！

また、これを利用して特定のコードがどのようにリファクタ可能かを画面上に出力するアプリケーションを作られているようです。
Rubularのようなイメージとのことで、とても便利そうでした！

パーサーによって結果が異るようなので、自分でも試しにコードをパースしてみたくなりました。
また、何か特定のコードパターンを検出しなければいけないとき、ASTとパターンマッチが使えることも覚えておきたいです。

あとお話ししてる姿が外国のテレビショーの司会みたいな感じでかっこよかったです！

Day2

Leveraging Falcon and Rails for Real-Time Interactivity by Samuel Williams

Falconという作成中のwebサーバーを使って、Railsでリアルタイムなインタラクティブ性を持ったゲームが作れるとお話でした！
レトロPCの起動音というエモい始まりから、コンピュータ通信とゲーミングの歴史を追った後、RubyでAsync gemと、それを前提として動作するFalconという新しいwebサーバーについて説明してくださいました。

そして、RailsとFalconを使って作ったゲームとその作り方を、コードと実際のゲームを見ながらお話してくださいました！
途中ステージ上にMatzが上がり、出来上がったゲームを実際にプレーするという場面もありました。
ほんとにRailsでゲームが動いてる・・・と感動しました！
自分でもいつか何か作ってみたいです！！

Community-driven RBS repository by Masataka Kuwabara

発表資料

色々なgemのRBS型定義を集約している、gem_rbs_collectionリポジトリの管理運営に関しての発表でした！
gem_rbs_collectionはRailsをはじめいろいろなgemの型が集約されており、コマンドを実行することでその型定義をインストールすることができます。

元々はcode ownerと呼ばれる人を決めて、その人だけが変更をマージできるような運用だったそうですが、レビュー時にレビュー時に各gem自体についても理解しなければならず、レビュー負荷が高すぎるという問題があったそうです。
これをどうにかするために、現在はコミュニティドリブンという方針で進めているそうです。

具体的には、一部のgemにはgem reviewersを設定し、その人たちがチェックしないとマージできないこととしつつ、gem reviewersがいないgemについてはコントリビュータが自分で修正をマージできるというルールで運用しているとのことです。
syntaxチェックやコントリビュータ自身が書いたテストさえ通ればマージされる状態ですが、gem_rb_collectionsは型定義であり実行されるコードではないため、個々のリスクは許容できると考えているとのことでした。
また、GitHub actionsによりPRへのウェルカムコメントやマージフローも自動化しており、コアメンバーへの負担ができるだけ低くなるようにしているようです。
こうした工夫で大部改善されてはいるものの、現状特にRails関連のgemの型情報が足りていないのが問題とのことでした。

コミュニティドリブンという言葉の通り、今はかなりフラットにコミュニティによって維持されるリポジトリとなっているようです。
運用上の工夫によってサステナブルなプロジェクトになっているのが素晴らしいなと思うと同時に、それを維持する方々に改めて感謝しなければと思うお話でした。
チャンスを見つけたら積極的にPRを上げたいと思いました。

Embedding it into Ruby code by Soutaro Matsumoto

発表資料

RBSの型情報を、別ファイルに定義するのではなく、プロダクトコードの中にインラインで書けるようにするというお話でした！
RBSの良さはプロダクトコードと型定義が分離していることだと思っていたので、それがなくなってしまうのかなと心配でしたが、コメントとして型アノテーションのような書き方をできるということのようです。
確かにこれならRubyのコード部分はそのままだし、後からやっぱり型付けいらないとなって排除したとしても、コメントとして無視されるだけなので、問題は少なそうです。

型定義ファイルをプロダクトコードと分ける方式だと、例えばプロダクトコードから一つメソッドを削除するだけでも2ファイル修正せねばならず、型定義修正の漏れが発生しやすいという問題点がありました。
インラインで書けるようにすることで、このような問題を回避できます。

こちらの機能は現状rbs-inline gemとして作成されていますが、将来的にはRBS本体に組み込んでいく想定のようです。
現状はまだプロトタイプでシンタックスも検討中とのことですが、すでに改行やインライン（コードと同じ行につづけて書ける）に対応した書き方なども実現されていました。

RBSがより洗練されて、実用的になってきていると感じました！

Unlock The Universal Parsers: A New PicoRuby Compiler by Hitoshi HASUMI

PicoRubyにLramaから生成されたパーサを組み込むというお話でした！
現在RubyにはPrismという手書きパーサが内蔵されており、そちらは他と比較してRAM消費量が小さくコンパクトに組み込めるのですが、現在Lramaの開発が盛んに行われており、今後もどんどんアップグレードして改善されていく予定となっているので、なんとかこれをPicoRubyでも使うために頑張ったという内容でした。
Lramaが生成するパーサを利用した場合のRAM消費は、そのままだと他と比べて三桁ほど大きかったのですが、内部の依存関係で剥がせるものをどんどん剥がしていき、コンパクトにしていくことでPrismに近いレベルまで改善されていました。
具体的にどこをどう剥がしていったというお話もあったのですが、不勉強で全くついていけませんでした・・・😭

多くのCRuby以外の多くのRuby実装ではPrismが広く採用されているとのことでした。今回PicoRubyで使えるレベルにするというお話でしたが、いろいろなRuby実装での利用可能性を示すという意義もあるようです。

パーサまだまだよく分かりませんが、ユニバーサルパーサとしていろいろな環境で使えるようにすることがとても重要視されてるということだけはわかりました！

RuboCop: LSP and Prism by Koichi ITO

発表資料

LSPを使うとRubocopが速くなるというお話と、Rubocopで使用するパーサをPrismに切り替えられるというお話でした！
Rubocopは現在LSPを立てて実行できるようになっています。
Rubocopは起動に時間がかりますが、常時起動しておけばその時間を削減できるためレスポンスが速くなります。

この変更によって速度が改善されたものの、今度はエディタ上で常時監視して自動修正できるようになったため、コードを書いてる途中でも意図せずオートコレクトが走って辛いという新しい問題が出てきました。
これに対し、エディタにおいてはコードを書いている途中の状態が多いが、CLIでrubocopコマンドを実行する場合は大体書き終わった状態だろうと想定し、.rubocop.ymlのAutoCorrectの値をそれまでのtrue/falseの2値から、always/disabled/contextualの3値で設定できるようにしたそうです（contextualの時はCLIでは自動修正できるがエディタ上では自動修正されない）。

しかしここでPrismというエラートレラントなパーサが登場し、またそれによってRubocopがが高速化するという報告もあったため、今度はパーサの切り替えについて検討することになったそうです。
koicさん曰く、Prismは従来から使用しているParserと同一のASTを出力するトランスレーション層を設けているなど、使用者のことをよく考えて作られているとのことでした。
Rubyのパーサは現状LramaとPrismの２候補があり、どちらが最終的にメインとなっていくかはまだわからないようですが、少なくともAPIは現状のPrismのものが採用される見通しであるため、RubocopもPrismに対応し、.rubocop.yml内に設定を追記することで使用パーサを切り替えられるようにしたそうです（現状は実験的な機能）。

しかし現状のRubocopはPrismのASTそのままではなくParserのASTに直しているため、エラートレランスなものになっていないそうです。
PrismのASTを直接使うためには、Rubocopの機能に加え全Copsの改修が必要となるため、すぐの対応は難しそうだし、そもそもフォーマッタにおいてエラートレランスがそこまで必要とされるのか？という点もまだ検討中のようでした。
LramaとPrismのどちらがメインとして採用されるかというところもあり、本番使用においても新しいパーサを使うようになるのはまだ先のお話になりそうです。
Rubocopは日頃最もお世話になっているツールの一つですが、その機能改修がどのように進んでいるのかを垣間見れる発表でした！

Good first issues of TypeProf by Yusuke Endoh

発表資料

TypeProfの現状と、開発に参加する場合のフローについて説明してくださいました！
TypeProfはRubyの型解析器で、Rubyのコードを読んでRBS形式の型を出力してくれます。
まだ開発途中のため、一部のRuby構文に対応していませんが、VSCodeの拡張もすでに用意されており、エディタ上で推論した型を表示したり、型違反にエラーを出したり、定義ジャンプや使用箇所のリスト表示などもすでに実現されているそうです。
現状はほぼ一人で開発を進めている状況なので、誰か手伝ってくれる人を募集中とのことです。

現在TypeProfの開発は、TypeProf自体のコードを解析する形で進めているとのことです。
大まかな流れとしては、

  1. 各構文の解析結果についてのテストシナリオを書いて失敗確認
  2. 実装
  3. テストをパスすることを確認

という感じだそうです。
TypeProfで遊んで変なところを見つけたら、テストシナリオを作ってくれるだけでも大歓迎とのことでした！
また、より難しい開発タスクとして、エラーメッセージ表示・ハイライト・定義ジャンプ・自動補完といったエディタ拡張機能の改善や、フロー解析の改善、ruby-lspへのプラグイン化、Embedded RBSへの対応なども積まれているようです。

コントリビュートチャンスがたくさんありそうと感じました！
VSCode拡張についても学ぶ機会を得られそうです。

Lightning Talks by

2日目のラストはLT枠で、全部で11件の発表が行われました！
LTは各5分、時間が来たらtompngさんの銅鑼による合図で強制的に交代というルールでした。
（発表者の皆さんタイムキープバッチリで、全ての発表が時間内に収まってました！kanekoさんだけ、余った4秒でさらにパーサーを話そうとして間に合わず退場となり笑いを誘っていました）
どの発表も魅力的でしたが、

  • 実行中のRubyプログラムサクッとプロファイリングできるMetricsMonitor Gemを作ったお話
  • コードでお絵描きをするクリエイティブコーディングが楽しいというお話
  • kanekoさんのパーサーマシンガントーク
  • PicoRubyとR2P2によりRubyのコードを書くだけでラジコンカーが動かせるというお話

あたりが特に印象深かったです！
LT以外の発表もそうですが、皆さんRubyと楽しく向き合っている感じでいいなぁと思いました。

Day3

Ruby Committers and the World by CRuby Committers

Rubyコミッターの皆様が壇上に上がって公開討論する時間です！
ざっくり以下のような話題が議論されていました。

  • Ruby3.4からLiteral Stringがデフォルトでfrozenになることについて
    • 大体の人は賛成だけど、一部大反対の方がいる（特に特殊なコード（quine）を書く人）
  • Embedded RBSについてぶっちゃけどう思うか？
    • 「現時点でのソリューションとしては黙認できる」by Matz
  • CRubyのビルドシステムつらいんですけど
    • Matzのせいじゃないかと・・・
  • GVLをremoveするか？
    • 速くなる前に壊れる
  • いろんな言語でasync await流行ってるけどべつに良いものじゃないと思ってる
    • 「他の言語のことを悪く言うのは良くないけれど、あれで読みやすくなったと思ってる人はどうかしてる」by Matz
  • Goのdefer機能はRubyに入りうる？
    • 文法といい名前が決まれば
  • RubyCentralから日本のRubyistの皆さんへの言葉
    • RubyConfに日本人も参加しやすくしたい

恒例企画ですが、議論の内容自体もさることながら、私としてはRubyコミッターの皆さん同士の会話風景を生で見れるのが嬉しかったです！

Turning CDN edge into a Rack web server with ruby.wasm by Kay Sawada

発表資料

WASMを利用し、RackアプリケーションをCDNのエッジサーバ上で動かすというお話でした！
CDNは通常静的コンテンツの配信に使われるものだと思いますが、WASIを使えばランタイムごとRackアプリケーションを配信できるということのようです。
発表の中ではデモアプリの他、Sinatraで作成している個人ブログの配信にも成功されていました！
これを実現するために具体的に必要だったコードの修正なども含めて説明してくださいました。
その他Rails等も試されたようですが、そちらは残念あがらうまくいかなかったようです。

CDNエッジサーバーは世界中に配置されており、コンテンツがリクエストされるとユーザーに最も近いサーバーから配信されるので、遅延を最小限に抑えることが可能です。
2日目のキーノートではFalconを使ってリアルタイム性のあるゲームを作るお話がありましたが、それと組み合わせたら何か新しいものができたりするのかも・・・！
未来を感じるお話でした！

Ruby and the World Record Pi Calculation by Emma Haruka Iwao

発表資料

円周率計算の世界記録を更新するプロジェクトの中でRubyを活用した時のお話でした！
円周率の計算システムの構築において、1%の改善で計算時間を1日短縮できるそうで、そのために各種パラメータの設定が非常に重要なようです。
設定はYAMLファイルにまとめられているのですが、各設定値をERBで動的にセットできるようにしていたということのようでした。
（実験結果の整理の方はLinuxのシェルコマンドを使ったとのこと。そちらはトライアンドエラーが必要で、そのためにはコマンドラインが適していた。）
Rubyの良さの一つでもある手軽さを感じるお話だなと感じました！

また、ご自身にとって最初のRubykaigiであったRubyKaigi2009やRailsGirlsへの参加などにも触れ、それが現在のキャリアにつながっているというお話もありました。
発表後、会場を出ていくオーディエンスの中から「いい話だったね・・・」という声が聞こえてきました！

Porting mruby/c for the SNES (Super Famicom) by Ryota Egusa

発表資料

mruby/cをスーパーファミコンに移植したというお話でした！
発表の中では、移植方法やデバッグに苦労されたお話など詳しく説明してくださいました。
スーファミはPPUというものが画面出力を担っており、BGとspriteがそれぞれ背景やキャラクターを表しているなど、スーファミの内部使用的な部分についての説明もありました。
特に、（多分ブラウン管テレビを想定しているので）電子ビームの走査についての仕様があり、それによって画面表示の演算にはタイミングの制約があって、そこをうまく調整できないと画面がチラついてしまうというのが印象的でした・・・！
また、テキスト出力がないためデバッグがとても難しく、エミュレータを使ったり、特殊チップと呼ばれるゲームカセットの方に内蔵されているチップを使ってどうにかしたりと、色々な工夫ををされているようでした。

最後には、実際にスーファミの筐体を使って、実際にRubyで動くゲームのデモを見せてくださいました！
スーファミのコントローラで実際にキャラクターが動いていて感動しました！
偶然なのか、ゲームの内容が２日目キーノートのFalconで作成されたゲームととほど同じ内容だったのも驚きました・・・！

Using Ruby in the browser is wonderful. by Shigeru Nakajima

発表資料

ruby.wasmへのコントリビュートしたお話と、Rubyによるフロントエンドのフレームワークのお話でした！
中島さんはruby.wasmの中でも、RubyとJSの架け橋となる部分に主に貢献されているとのことでした。
具体的には、JSのオブジェクトを、それまでJS.evalにJSのコードを渡して実行していたところ、JSの変数に対して.newを実行できるようにしたり、ブラウザ上でrequire_relativeみたいなことをできるようにしたなどの貢献をされているそうです。すごい・・・。

また、現在Rubyでフロントのフレームワークを作っているそうです！
ある程度抽象的なフレームワークが、120行のRubyのコードで実現できたとのこと・・・すごい・・・！

フレームワークはOrbital Ringという名前にしたそうです。「地（バックエンド）にはRails、空（フロントエンド）にはOrbital Ring」という対比でつけた名前とのこと。洒落てますね。
ブラウザ上で動くRubyの新しい可能性を感じる発表でした！

Matz Keynote by Yukihiro "Matz" Matsumoto

RubyKaigi 2024のラストはMatzのキーノートでした！
色々笑いどころも用意されていて、終始楽しく聴けました。
Rubyをより良くするには？というテーマで「４つの側面」についてお話してくださいましたが、結果、パフォーマンスが全てを解決するということで、その４つというのは全部パフォーマンスというオチでした。
ただ、パフォーマンス改善は以下のような複数のアプローチで検討されているということでした。

  • YJITの更なる高速化
  • メモリ関係の改善
  • コンカレンシーの更なる活用
  • パーサの改善によるツールの発展と、それによる開発体験の向上（これは開発者のパフォーマンス改善）

また、Rubyの未来というテーマについても触れられていました。
2004年ごろ、いろんな言語で「これまでのしがらみを捨てて新しくリスタートしよう」という動きがあったそうです。
結果から言えば、互換性が無さすぎて結局使われなかったり、コミュニティの分断につながったりと、あまり良い結果にはならなかったとのこと。
当時Rubyでも同様にRuby2という構想の元、新しい機能が色々と検討されていた時期があったそうです。
Rubyの場合は（Matzがめんどくさがりだったから）結局Ruby2が2が実現されることはなく、その時に生まれたアイデアは通常のバージョンアップの流れの中で実現されていったようですが、その時にNamespaceのような機能もアイデアとして上がっていたとのことでした。
今年になって、ついにそのNamespaceが実現されようとしており、「これが入ったら、Ruby4.0と言ってもいいかなと個人的には思ってる」とおっしゃっていました！すごい！
それだけRubyにとってインパクトのある出来事なんですね・・・！

また、最後にはSDGsに触れ、今のRubyは実行時の効率はそこまでではないから、データセンターで消費される電力や水資源が少ないRubyというのもありうるかもとおっしゃっていました。
ちょっと冗談っぽかったですが、広く使われる言語なので、実行効率が上がった時の省エネ効果は実際ありそうと感じました！

一人思ったこと

ありがたいことに何人かの方ともお話ししたり、お昼をご一緒させていただいたりしつつ、会期中基本的にはずっと一人で過ごしていました。
せっかくの交流機会をそういう感じで過ごしちゃうこととか、あまり技術に積極的になれていないのにRubyKaigiのような場所に行くのがなんだか恥ずかしいというか、心苦しかったりもします・・・。
それでも現地に行って、ひたすら楽しそうなRubyistの皆さんの姿を生で見れるのは本当に楽しかったです！
改めてRubyコミッターの皆さんやGemを作ってくださっている方々には感謝しかなく、（なかなか行動に移せていないものの）いつか自分も何かしらの形で貢献してみたいと思った３日間でした。
来年のRubyKaigiにも参加できるように、また1年頑張りたいと思います💪

Discussion