RubyKaigi 2019 Day1 レポート「 The Matz Keynote! 」まとめ

はじめに

2019年4月18日から21日にかけて福岡で開催される RubyKaigi 2019 に参加してきました．
Day1 の Keynote をメモったので本記事でまとめたいと思います．
間違っている箇所があれば優しくご指摘下さい

Keynote

Day1 の Keynote は Ruby の生みの親である Matz によるもの
Keynote のタイトルは「 The Matz Keynote! 」
前回の RubyKaigi 2018 では ”名前重要” など Ruby という言語コミュニティが大切にすべきコンセプトについて話しており，割と抽象的な話がメインだった
今回の RubyKaigi 2019 では Ruby3 の話がメインとなっており，前回よりもテック寄りな内容になっていた
以下にその内容をまとめていく．

現在の Ruby について

始めにアイスブレイク的な話として，現在の Ruby について語られた

Ruby is ~

Ruby is Good

Ruby はいいと言われている

• Productive
• Flexible
• Fun

Ruby is Bad

一方で Ruby は悪いとも言われている

• Performance
• Multi-Cores
• Bigger Team/Project

Ruby is Good Enough

それでも Ruby は大体のことには十分に良い

• Github
• Airbnb
• Instacart
• Cookpad

よく遅いと言われるが，上記のような複数の大きなサービスに利用されており，かつ実用レベルなことを考えると Ruby は十分に早い

Ruby と Twitter

Ruby の話をするときにいつも Twitter が引き合いに出される

Twitter が Ruby をやめたから Ruby はもうダメだと言う人がいるが，
そもそも Twitter のようなサービスに Ruby は向いてないし，
10年経っても Ruby は全然生きてる

Ruby の実行速度

Ruby1.8 は遅かったけど， Ruby1.9 以降はだいぶ早くなった．
Ruby2 は2013年にリリースされたが，性能改善を続けてきてちょっとずつ性能は良くなって来ている
Ruby3 はより頑張る

Ruby3 で改善されたこと

ここから本題

Ruby3 で大きく改善された3つのこと

• Performance （性能）
• Concurrency （並行性）
• Static Analysis （静的解析）

1. Static Analysis

１つ目，先に静的解析の話から

Ruby のスタンス

最初に Matz のスタンスについて話があった
その後，他の言語における静的解析について話があり，
Ruby のスタンスについての紹介された．

Matz はテストが嫌い

本当はテストを書きたくない
「It's not DRY. (DRY じゃないから)」

テストの記述量が少なければ機能の実装に集中できるのでとても生産的
でも人間はミスをする生き物だからテストを書かざるを得ない

他の言語はどうしているか？

他の言語は静的解析にどのように取り組んでいるか？
→ 型注釈を導入している

• Python: Type Hints
• PHP: Typed Properties
• JavaScxript: TypeScript

など,型注釈は最近のトレンドっぽい

じゃあ Ruby はどうするか？

型注釈は入れない
他の言語は入れてるけど入れたくない
型注釈嫌い
「It's not DRY. (DRY じゃないから)」

DRY じゃないものをタラタラ書くのはコンピュータに仕事させられている感じがある
人間がコンピュータに仕事させるべき
テストは妥協するけど静的解析には妥協しない

Ruby3 のプラン

型注釈はやらないけど，型チェックはやる

Ruby3 では4つのコンポーネントを入れようとしている

• 型定義文法
• ライブラリの型定義
• Type Profiler
• Static Type Checker

型定義文法 (Type Signature Format)

ruby のコード自体は変えず，外部に型を定義するファイル（.rbi）を用意する
rbi File は自分で書き直すことが可能

Type Profiler (Level-1 Type Checking Tool)

Type Profiler で警告する
型の情報を集めて，すでに定義されている型情報と矛盾があればエラーを出す
自動生成は頑張っている．けどできてない

ライブラリの型定義 (Type Signature Prototyping Tool)

型推論のようなことをする，実際は違う

Static Type Checker (Level-2 type checking tool)

トラディショナルなやつ

• Sorbet
• Steep

など．
Sorbet は Fast で Nominal だけど Ruby っぽくない

こういうの入ると型注釈を書かなくても型チェックすることができる

Ruby3 の型チェック

型チェックについてはすげぇ頑張ってる
各内容については個々の講演を参照してね
3.0 は期待していいよ

2. Performance

二つ目， Performance 改善の話
Performance （性能）， Concurrency （並行性）， をまとめて

プログラミング言語の悲しき運命

そもそも，どんな言語も早すぎるといわれることはない
どんな言語も遅いって言われる
ただ ruby は伝統的に遅いって言われる 😢

より多くのトラフィックを処理するには

mruby とか JIT の開発を手伝って頂いている中国の方と話した結果，以下のような知見を得た．

Memory is the First Bottleneck

→ GC の改善が重要

Fragmentation の改善は意外と容易

しかし，実際の問題はそれだけに留まらない

Memory is not the only Bottleneck

→ CPU とか I/O も Bottleneck になる

Just in Time Compiler の存在

MJIT を去年導入した

良い点

• Portabele
• Reliable
• Optimized

悪い点

• Heavy
• Inefficient(Memory-wise)

CPU ボトルネックに関して， 2.6 は 2.0 に比べて８倍早い
ただ， Rails に関しては遅くなる (MJIT Runs Slower)

理由はいくつかある
非常に沢山のメソッドをコンパイルする必要がある
たくさんのスレッドが起動している
など

Multi-Cores の活用

去年，マルチコア活用に関してはあまり進んでいなかった
今年はがんばる

WWW はもともとマルチコアに向いている

今の Ruby は Thread, Fiber を持っているが，ボトルネックの改善は難しい

より良いコンカレンシーモデルの提供

状態を共有しないのが重要
Shared State は良くない

Erlang / Elixer は Data Immutable なので安全
Immutable は良いけど，今更 Ruby に導入できない（そもそも Ruby は出自が違う
）
その代わり Guild を導入した

Guild は分離されたオブジェクト
チャンネルの受け渡しはイミュータブル

Guilds ≒ actor
Guilds ≒ Web Worker(JS)
Isolated Block
これ導入するとマルチコアを有効に活用できそう

慣れるまでは使いづらいけど……

I/O 改善

Non-blocking I/O が重要

Node.js を参考にしてる

AutoFiber
I/O 操作のコンテキストスイッチが今までの Ruby のように時間で切り替わらない．

Avoid I/O blocking

AutoFiber が導入されたら現在のスレッドはだんだん消えていくだろう
というか Ruby にスレッドを入れたことは後悔している……．

マルチコアとかマルチスレッドの時代がくるとは思わなかったんだもの．

名前決めで紛糾

Guilds(Isolates)
AutoFiber(AsyncWhatever)
名前と役割が異なるから名前決めで紛糾している

他の言語は一つしかないよ

• Go: goroutine
• Elixir: process

他の言語は初期からそういう設計してるけど， Ruby は違うから使い分けるしかないよね
今までの Ruby を動かなくするわけにはいかない

われわれに必要なのは名前

Static Analysis
Keeping Compatibility
互換性を維持しながら，いろいろ発展していきたいよね

Guilds って名前はゲーム業界からすげぇクレーム来てるけど……

3. まとめ

以下，まとめ

今回導入されないもの

Frozen Sting Literals(3.0 では導入されない，断念した)
Obsolete '?' Literals(3.0 ではなくならない)
Obsolete Backquotes(3.0 ではなくならない)

Keyword Argument は変える
静的型づけと相性わるそう……どうなんだろ？

Numbered block parameter
[1,2,3].map{@1 *2}
一番目のパラメータにアクセスできる
もう入っているけど紛糾したので考えさせて．
(@ はインスタンス変数に見える)

（関数型言語の）パターンマッチングについて

昨日マージされた．ぜひ試して秘孔を突いてみて．

Ruby の今後

我々は生き残らなければならない
Ruby 好きだし，仕事なんすよ，ご飯食べないと
Python とか JavaScript とかに行きたい人は行けばいい
ただ， Ruby がこの先生きのこるために賢く選択していく

ユーザに Ruby を使い続けてよかったと思って欲しい
前進し続けたい
闇雲進むのではなく賢く進みたい
賢く進むのは一人ではできない
後悔はたくさんしてる（特にスレッドやキーワード引数，なんで入れちゃったんだろう……）
自分は天才じゃないからこういう失敗もする．

今の Ruby は良くも悪くも使う人がたくさんいるので直しづらい
どんな些細な機能でも使われる
そのため，賢く選択しなければならない
決まってしまったことは変更できないので決まる前に言って下さい
Ruby を作り続けて世界を良くしたい

コミッターの方々によって Ruby の世界は良くなってきた
これからもよろしくお願いします
たくさんの意見下さい．

（この記事の）まとめ

Keynote の書き起こしってかなり疲れますね．
今回の記事では Keynote の焦点を当てましたが， 機会があれば Keynote 以外にも焦点を当てて記事化したいです．
Qiita には私が聞いた内容をまとめましたが，

会社のブログには，同僚が書いた記事も載っているのでそちらも合わせてご覧下さい．
http://nekojarashi.hatenablog.jp/