こんにちは、趣味エンジニアのめる（@c5meru）です！
UUUMに入社して1年と2ヶ月が経とうとしていますが、自分が入社した時、現場のエンジニアは5人くらいしか居なかったのに、いま数えてみたら現在22人もいるようで、そのスケールの違いに圧倒される日々を送っています。
さて、自分は先日、会社のカンファレンス参加制度を利用して RubyKaigi2019 に参加してきました。
今回が初めての RubyKaigi なので書きたいことがたくさんあるのですが、こちらのUUUMエンジニアブログでは、1日目に行われた、まつもとゆきひろさんのKeynoteでお話があった内容について書かせていただきたいと思います！
The Year of Concurrency by Matz
- Rubyは「だいたいのことにはいい」
- チームやプロダクトが大きくなるとデメリットが見えてくる
- 他の言語と比較して遅いのは、マルチコアを活用できていないから
- Github cookpad Airbnb などもRubyを使っている
- これらよりパフォーマンスを求められるサービスはあまりない
- だから「十分に速い」とも言える
- パフォーマンスが良くないっていう人もいるけど、特筆する例はTwitterの一件だけ
- しかも古いバージョンであった1.8を使い続けていたケース
- Rubyは今までも性能の改善を続けてきたし、Ruby3でも改善を進めている
- Ruby3のポイント
- 静的解析
- パフォーマンス改善
- Concurrency
- Ruby3のポイント
静的解析
- プロジェクトが大きくなってくるとテストのサイズや実行時間が長くなって苦痛になってくる
- Matzはテスト嫌い、できれば書きたくない
- DRYじゃないし
- でも人類は間違いのないプログラムをまだ書けないから仕方がない
- JSのTypescriptや、他の言語でもtype hintingがある
- Matzは型宣言が嫌い、できれば書きたくない
- DRYじゃないし
- コンピュータに仕事させられてる感じがする
- だからここは妥協したくない
- なくてもプログラムを書くことはできるから
- けどできるようにするために進めている
- 型定義シンタックス .rbi
- 静的型チェッカー
- Stripe さんの Sorbet と soutaro さんの steep がある
- rbiに対応できるように進めている
- 型宣言を書かなくても型チェックができるように進めている
- Gems で型定義ファイルを配布すれば、既存の型情報はカバーできるから
パフォーマンス改善
- alibabaでもRubyは使われているらしい
- メモリがボトルネック
- なのでGC周りの改善、キャッシュの改善をすすめている
- CPUもボトルネック
- 昨年はMJITを導入、メリットもあったがデメリットも多くあった
- Ruby2.6ではベンチマークで使っているファミコンエミュレータは2.8倍早くなる
- RailsなどのWebアプリケーションは、たくさんメソッドがあってコンパイルする量が多くなるので遅くなる
- PHP8のパフォーマンス改善も同様だそう
Concurrency / 並行性
- IOボトルネック
- 現状の Thread/Fiber にも課題を感じている
- オブジェクトを今からイミュータブルにはできない、過去の経緯があり破壊的変更になってしまう
- Guild（仮称）をつかう
- ゲーム業界から反対が出た（このClass使ってるんだけど）
- frozen objectのようなイミュータブルなものだけ送れるように
- GuildはJSでいうwebworkersみたいなもの
- Guildは慣れるまでは使いづらい、IOボトルネックを解消するにも使いづらさがある
- シングルスレッドのNode.jsはどうしているのか
- ノンブロッキングIO
- V8のパフォーマンス
- AutoFibers（仮称）でIOブロッキングを避けられるようにすすめている
- Goはgoroutine
- Elixirはprocess
- Rubyはそういうのを当初考えていなかった、破壊的変更を避けるために、気をつけながら改善している
メンテナンス方針
- 互換性を維持しながら改善するのは難しい
- Ruby3、その先も、いろいろ改善してRubyをGreatにしたい
- Frozen String Literalsは3.0がデフォルトにはまだできなかった
- emacsからもってきた '?' literalsも、3.0では消せなかった
- バッククオートも、3.0では消せなかった
- キーワード引数は、3.0で変わる
- もともと直感的でなくわかりづらいと思ってた
- 静的型付けと相性が悪そう
- 大きな非互換になる見込み
- 2.7から警告を出すそう
- numbered block parameter
- すでに trunk では導入されているが、議論が続いている
- まだやらない
- パターンマッチング
- 昨日 trunk にマージされた
- Rubyは生き残らなければならない
- わたしたちはRubyが好きだし
- Rubyのプロダクトがすでにたくさんあるし
- わたしたちはRubyでご飯食べてるし
- でもみなさんは、JSでもPythonでも使ってもらっていいんですよ
- わたしたちコミッターは、Rubyがなくなったら本当に困る
- よりよい、よりたのしい、より生産的な言語に
- Rubyを使うことがメリットになるように
- たまに後悔するような実装もしてしまう
- キーワード引数、Threadなど
- ユーザーが多いから直しづらい
- もう間違えないようにしなくては、と慎重にやっている
- みなさんの意見をないがしろにしたくない
- 決まってからでは変えられないので、決まる前にどんどん意見を言ってほしい
- 最近はもどかしいけれど、Matz自身は設計だけ考えて、実装は他のコミッターにやってもらってる
- Cが書ける人がいたらぜひ参加してほしい
その他
Keynoteの次のセッション「Ruby 3 Progress Report」では、上記よりもさらに踏みこんだ、Ruby3の開発進捗がお話しされました。
Matzさんとは対照的に、自分はテストも静的解析も好きなので（笑）、特に静的解析の仕組みは非常に興味深く、Ruby3が今から待ち遠しくなりました！
上記にもあったキーワード引数の破壊的変更では、この変更だけのために何度も何度も開発者会議が開かれたという話を聞いて、日頃わたしたちが使っているRuby（などのプログラミング言語）は、たくさんの方が時間をかけて作ってくださったものなんだな、ということを実感しました。ありがたや...！
また、RubyGemsのアカウント乗っ取りが多発しているという注意喚起もあり、RubyGemsアカウントを持っている方は、必ず2段階認証を設定してほしいということでした！
まとめ
セッション以外のことについては、個人ブログの方に書かせていただきましたが、全体的にお祭り感もあって非常に楽しいカンファレンスでした！
RubyKaigiをもっともっと楽しむには、Rubyのしくみを読んだり、（関連するセッションが多い）mrubyを押さえておいたり、英語力をがんばって高めておくと良いだろうな、と思ったので、今後参加される方は参考にしていただければと思います！
