【Ltech#0】RubyKaigi2018報告会 Ruby2.6に関する情報と参加した講演で気になったところ

Ruby2.6に関する情報 と 参加した講演で気になったところについて 株式会社LIFULL LIFULL HOME’S事業本部流通事業部UXU 吉田 希

アジェンダ • 自己紹介 • RubyKaigi2018概要 • Ruby2.6にまつわる内容 • 聴講した講演からいくつか • • • • RubyGems Rubocop Guild TypeDB, TypeProfiler • 総括と所感

自己紹介 • zom@Qiita • LIFULL入社10年目 • 好きな言語：Ruby • 書ける言語 • Ruby • PHP • js • 趣味：自炊 • anovaで低温調理

RubyKaigi2018概要 • 5/31(木) - 6/2(土) • 国際センター＠仙台 • 参加者1017名 • この規模は過去最大 • 外国の方も多く体感値3割くらい • スポンサー71社 • LIFULLもプラチナスポンサーとして参加 • Ruby2.6の最新情報が目玉（？）

Ruby2.6にまつわる内容 • Ruby2.6.0-preview2がRubyKaigiの初日である5/31に公開 • • • • • • JITコンパイラ Endless range Proc#callの高速化 block.callの高速化 yield_selfの別名thenの追加 RubyGems3の導入 • preview3は9月を予定 • 多段backtrace機能を追加予定 • Ruby2.6.0は12月25日にリリース予定

Ruby2.6にまつわる内容 • JITコンパイラ • Cのコードとしてファイルに書き出しCコンパイラでネイティブコード に変換 • CとGCCコンパイラ環境が必要(VisualC++, IntelC++Compilerでは動かない) • OSもFreeBSDでは動かないなどいくつかの制約がある • 現段階ではプロダクションで使うと確実に動かない • OptCarrorではRuby2.0に比べると2倍速くなった • Railsでは遅くなった • 一定の条件下でオーバーヘッドが発生する（修正予定） • Ruby→C→（ここ）→Rubyが遅いらしい https://speakerd.s3.amazonaws.com /presentations/fc4bc2035f8a497a8fd3dc801aa7a168/rubykaigi2018_k0kubun.pdf

• https://speakerd.s3.amazonaws.com/

参考：OptCarrotの例

Ruby2.6にまつわる内容 • Endless range

Ruby2.6にまつわる内容 • Proc#callの高速化 • block.callの高速化 • yield_selfの別名thenの追加 • https://bugs.ruby-lang.org/projects/rubytrunk/repository/revisions/63525 • Matz自身が5年ぶりにコミットしたことで湧いた

• https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/63525

https://twitter.com/hsbt/status/1002476626020483072 https://twitter.com/hsbt/status/1002473972863156224

聴講した講演からいくつか

RubyGems • 今までの話 • 現行の最新は2.7.7 • もう2.5と2.6はセキュリティメンテナンスしかされない • Ruby1.8対応 • Object#respond_toでメソッドの有無を確認してifで分岐して対応… • これからの話 • • • • Ruby2.6.0-preview2には3.0.0beta1がバンドル 3.0はRuby2.2以上を対象 上記のようなif分岐を削除 今後deprecateになるものにwarningを出す

RubyGems • Ruby2.7か3.0までに4.0をリリース予定 • 4.0ではすでにインストールされているgemはインストールしな いようにしてエコにする • --user-installのデフォルト化 • gem installするとシステム領域にインストールしようとして permission deniedになる • これは初見ユーザ殺しでRubyを嫌いになってしまう一因と考えている ため

Rubocop • 今までの話 • • • • • • 最初は正規表現で頑張ってた 次にripperを使うようになった これでかなり改善された しかしripperはMRIでしか動かない＆ドキュメントがほぼない クロスプラットフォームで動かしたいので脱ripperしたい parser(gem)を使うことで実現、ゴリゴリ修正 • ここまでで2012年5月から2013年7月までの流れ • 並列チェックやキャッシュなど様々な機能追加をしてlintツールとして の地位を確立 • 拡張機能も充実（189個） • rubocop-spec, guard-rubocop, rubocop-sequel, rubocop-caskなど

Rubocop • これからの話（Rubocop1.0について） • コア機能からRails用のCopを削除 • Rubocop拡張をしやすいようにAPIの提供 • mryでスムーズな移行を推奨 • https://github.com/pocke/mry • それでもRubyのサポートするバージョンや設定値の変更などい くつかの機能の変更はある

• https://github.com/pocke/mry

Guild • Ruby3.0より導入予定のThreadに代わる並列プログラミングモ デル • 複数のThreadによってGuildが構成され、Guild間で並列実行さ れる • Actorモデルという並行計算モデルを元にしている模様 • 残念ながら知らない領域… • Guild間で共有可能なオブジェクト、そうではないオブジェク トなど実例を交えて提示

Guild • 各種ベンチマークではコア数に応じて高速に処理できるケース とできないケースがある • 40コアでn個のフィボナッチ数を10万回求める • これはnの数によって異なる • 特定のディレクトリ以下のファイルの単語数を計算して一番単語数の 多いファイルを特定する • Guildを使ったほうが遅い • GCやオブジェクトの割当の際にGVLが発生するため • とはいえ実例を見る限りすごく簡単に並列処理ができそう

TypeDB, TypeProfiler • Rubyに型を入れないことを明言＠Matz • 将来的にコンパイラが進化して型を推測するような未来になり、型を 意識せずに済むのでは • その未来では自分たちで型を書いている現在のコードは陳腐化する • Matzが最終的なGoサインを握っているのでコアコミッタは Matzの要求を引き出す作業をしている • 様々な型チェックの仕組み(gem)が作られている

TypeDB, TypeProfiler • Steep • https://github.com/soutaro/steep • 設定ファイルに書いてチェックさせる方式なので言語仕様に影響しな い • Matz好みの方向性とのこと • Sorbet • 今回のRubyKaigiで発表された？ • 結構よくできているらしい • RDL • アカデミック界隈で重宝されている • Sorbetがなければ世界一では by @mametter

• https://github.com/soutaro/steep

TypeDB, TypeProfiler • Steepが方向性としては良いが手動で作るのは大変 • 将来的には自動生成されるとよい • その生成するための型情報を貯めるためのTypeDB • そしてそのDBへ入れる型情報を生成するためのTypeProfiler • RubyCode→TypeProfiler→TypeDB • 機械学習のようなイメージと個人的に解釈

TypeDB, TypeProfiler • RubyCode→TypeProfilerにするための手段 • 静的解析1 • 動的に生成されるメソッドなどは間違った推定をしがち • 静的解析2（TypeDBのプロトタイプを使用） • （まだデータが十分じゃないから？）間違った推定をしがち • 動的解析（メソッドのin/outをTracePointで解析） • 遅い • void型を推定できない • やりたいことに対してTracePointのAPIが足りない • まだ道半ば

総括と所感 • とにかく使いやすいように、楽しく書けるように、という想い や工夫が伝わってきた • • • • Guildで手軽に並列プログラミング RubyGemsの--user-intall TypeDBで自動型推定 RubocopでLint • Ruby is deadと毎年言われているがこの信念があれば死なない と思う

総括と所感 • 日本人でも英語で発表する • 英語マジで大事 • 普通にC言語やメモリの話がされる • 基礎マジで大事 • アセンブリの話をされたときはさすがにぽかーんとした • エンジニアとして刺激をもらえる

おわり