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

はじめに

株式会社ねこじゃらし エンジニアの村上です. 株式会社ねこじゃらしは2019年4月18日から21日にかけて福岡で開催される RubyKaigi 2019 のシルバースポンサーです. その一日目に参加してきたので,感想などを簡単にまとめようと思います. 他の講演内容に関しては同僚の中山さんが記述されているようなので,そちらに任せ, 本記事では Matz の Keynote について記述したいと思います.

Keynote

Day1 の KeynoteRuby の生みの親である 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 は大体のことには十分に良い

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

RubyTwitter

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

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

Ruby の実行速度

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

Ruby3 で改善されたこと

ここから本題

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

  • Performance (性能)
  • Concurrency (並行性)
  • Static Analysis (静的解析)

1. Static Analysis

1つ目,先に静的解析の話から

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 に比べて8倍早い ただ, 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 の世界は良くなってきた これからもよろしくお願いします たくさんの意見下さい.

(この記事の)まとめ

RubyKaigi では Keynote 以外にも Ruby に関する様々な講演が聞けます. 今回の記事では Keynote の焦点を当てましたが, 機会があれば Keynote 以外にも焦点を当てて記事化したいと思っています. 私が初めて RubyKaigi に参加したのは去年の5月でした. 当時は入社1ヶ月だったため, RubyKaigi に参加してもエモい話しかできませんでしたが,今回は講演内容もだいぶ理解できるようになっていたので,自身の成長を感じられとてもいい経験になりました. 次回も機会があればぜひ参加したいですね. それでは,ここまでお読みいただきありがとうございました.次の記事でまたお会いしましょう.