見出し画像

#RubyKaigi 2022 2日目レポート

ヨーシャ

引き続き、RubyKaigi 2022レポートをお届けします

同時通訳レシーバーの貸し出しブースにいることが多いヨーシャです。引き続き、 RubyKaigi 2022 のイベントレポートをお届けします。今回はどったんばったん大騒ぎだった2日目のことをお届けします。

Matzのキーノート：Matz節炸裂！

と、まずは Ruby の作者である Matz ことまつもとゆきひろ氏のキーノートに。いつも彼の話にはわくわくさせられます。
いきなり朝の挨拶から始まりましたが、ここまでのRubyの歴史からいろいろなことが語られました。"Ruby is too good to be a scripting language." と語られたり、「スクリプティング言語にはOOPは要らない」と言われたり、「誰もRubyなんて使わない。使っているのはPerlやPHP、Pythonだ」とか「Rubyにはキラーアプリがない」とか、挙げ句の果てには「おまえはRubyを作るべきではなかった。Perlに注力した方がよかった」とか「Rubyは遅い」とか「Rubyはオワコン。これからはAIや機械学習、Web3の時代だ！」とか「Rubyは死んでる、というか毎年死んでる」とか、ひどい言われようだったのです。
しかし、Matzは悪口を言われたからイライラしているのではないのです。批判が建設的ではないことにイライラしているのです。なお、Python の作者として知られる Guido van Rossum 氏とはフレンドリーな会話ができるのですが、一部の他言語信者の行いにはがっかりしているようで、

こんな言葉も……。なお、 Python 界隈にも知り合いが多い私としては少々複雑です。
そして、"Y" で終わる言葉は価値が高いモノが多いという言葉が飛び出しました。大事にしていきたいものの中に、"Community" や "Joy" などのいくつかの "Y" で終わる単語が挙げられたのですが、最後に挙げられたのがなんと "Money" で、これには正直びっくりしました。

就職氷河期生まれの私としては大事だってのはわかるんですけどね……。と、Rubyは相当数の企業で使われており、Rubyエンジニアの年収も上がっています。

そうなってくると、コミュニティは大きな鍵になるわけです。貢献するには以下の方法があります。

  • バグレポートや機能のリクエストを行う

    • https://bugs.ruby-lang.org/ に送る

    • プルリクは https://github.com/ruby/ruby に送る

      • でも、プルリクと機能リクエストは同時に送らないでね

      • 却下されるのも多いので落ち込まないこと

        • まあ、名前が原因であることも多いよ

  • Ruby の Gem （ライブラリ）を書いていく

  • 開発者のサポートを行

    • トリアージをするとか

    • タスク・バックログ管理を行うとか

  • 翻訳を行う

    • 各国語でドキュメントが読めるようにしたい

  • カンファレンスやミートアップを開催し、手伝う

  • 企業は Ruby エンジニアを雇用する

    • 実際にいくつかの会社では Ruby コミッターをフルタイムで雇用している

そして、お待ちかねの Ruby 3.2 の新機能の話です。まず、最大の変化はパフォーマンスの向上と WASM への対応です。私は業務では C# と JavaScript/TypeScript を使い、 Python も趣味などで使っています。とりわけブラウザ世界の公用語である JavaScript や Blazor によって一足先に WASM 対応した C# に追いつけ追い越せで進歩させている感があります。そして、 YJIT は Rust で書かれるようになり、 ARM64 でも動くようになりました。けっこう早くなったと噂の YJIT ですが、後ほどそれについて語られているセッションがありますのでそこでどのくらい早くなったか紹介します。他にもメモリアロケーションの改善や Data Objects の復活など、さまざまな機能が入るとのことです。
安定期に入った Ruby は、開発の生産性を上げようとツール開発支援を精一杯行っています。これからの Ruby の進歩にご期待ください！
そして始まる質疑応答タイム。 Matz が最も興味を持っているのは Erg というプログラミング言語だそうです。 Python にトランスパイルできる、堅牢性とシンプルさを兼ね備えた言語で、既存の Python ライブラリとの互換性も考えられているとのことです。他にもいろいろな質問がありましたが、ここでの紹介は割愛させていただきます。
なお、 Matz は2日目で帰ってしまいました。日程の都合だそうです。

"How fast really is Ruby 3.x?" by Fujimoto Seiji

Fluentd の中の人による、本当に Ruby は3倍速くなったのかというセッションです。3倍速いというと某赤い彗星が思い浮かんだりしますが、 Ruby では Ruby 3 × 3 という Ruby の速度を3倍にしようというプロジェクトが進められています。 Ruby というと Rails というぐらいに Rails が素早く動くことが期待されることが多いのですが、実のところ Rails のパフォーマンスを測ってみるとデータベースの I/O でのブロッキングなど Ruby サイドの努力ではどうにもならないことが数多くあったりします。その一方でクラウド向けのログ収集ツールである Fluentd では非常に多くの Ruby オブジェクトを扱いつつブロッキングを考える必要がないアーキテクチャーになっています。しかも、 Ruby 1.9.3 の頃から Ruby を同梱して配布してきた実績がある息の長いソフトウェアです。なので、 Ruby 自体のパフォーマンスを測定するよい指標になるわけです。
そこで、それぞれのバージョンの Ruby のパフォーマンスを計測してみたところ、 Ruby 3.2 で YJIT を有効化すると Ruby 1.9.3 の頃の3倍の行数のデータを捌けることがわかったそうです。
しかし、他のスクリプト言語と比べると Ruby の遅さが際立ってしまいます。以下のツイートは Fluentd と同じような機能を Perl や Python 、素の Lua や LuaJIT を適用した Lua などの各スクリプト言語のパフォーマンスを比較したグラフになっています。

まあ、とりあえず LuaJIT を適用した Lua は異様に早いとして、 Ruby のパフォーマンスが YJIT でどのくらい変わったが注目です。さて、その答えは……？

そう、残念なことに Ruby は素の Lua 同等のパフォーマンスをたたき出せましたが、 Perl や Python には及ばないという結果が出てしまったのです。ただ、確実に言えることは Ruby は着実にパフォーマンスを向上させているということだったのです。
そして、 Python の側も毎年1.5倍ずつパフォーマンスを改善していって、最終的にはパフォーマンスを5倍にする計画がマイクロソフトに所属する Mark Shannon さんを中心に進められています。なお、彼は PyCon JP 2022 のキーノートスピーカーだったりします。なので、パフォーマンスガチ勢の皆様は PyCon JP 2022 にも来てくれると嬉しいかな、と思っています。

アクシデント発生！

そして、2日目に発生したアクシデントとしては、会場のネットワークに障がいが発生し配信が止まってしまうという問題でした。NOCチームによる必死の復旧で何とか配信は復活したものの、スケジュールは1時間後ろ倒しに。なお、その途中で私も協力することになりかけたのですが全く効果が出なかったので最終的には会場の回線を借りて配信するはめに。なお、 RubyKaigi 2022 の会期中は別のイベント（伊勢型紙の展示会）も第2ギャラリーで開かれていたのですが、会場の回線を RubyKaigi で占有してしまってよかったのかと心配しています。
なお、お帰りになる Matz さんといっしょに写真を撮ることもできました。

Matz と

やはり、 Ruby を作ったといっしょの場にいられるという貴重な経験ができてよかったです。

2日目アフター

2日目のアフターはこちらのイベントに顔を出してきました。

配信停止に伴うスケジュールの遅れで開始時間を変更させてしまうことになった上に、スタッフでの後片付けもあって当初の時間より遅れて参加したのですが、和気あいあいといろいろ語り合えたと思います。その後にバーチャルな別のイベントもありましたが、2日目も何とか過ごせたのでした。
そして残るは最終日の3日目、お楽しみに。

この記事が気に入ったらサポートをしてみませんか？