RubyのパパMatzさんに、RubyKaigi2017の見所を聞いてみた


> この記事はVASILY DEVELOPERS BLOGにも同じ内容で投稿しています。よろしければ他の記事もご覧ください。

こんにちは、VASILYバックエンドエンジニアの塩崎です。
RubyKaigi2017の開催時期が間近に迫っていますが、皆さんの広島グルメ探訪の予定はいかがでしょうか？

さて、今年のRubyKaigiにはVASILYから4人が参加する予定で、そのうちの3人は初参加です。
発表の要旨はすでに公開されていて以下のページで確認できますが、まだどれを見て回ろうかを決めかねている人もいるかと思います。
http://rubykaigi.org/2017/schedule

そこで、Rubyのパパであり、VASILYの技術顧問でもあるまつもとゆきひろさん（以下、Matzさん）にRubyKaigi2017の見所を聞いてみました。
この記事がRubyKaigiに参加をされる方々の参考になれば幸いです。

# 1日目

## How Close is Ruby 3×3 For Production Web Apps?
[How Close is Ruby 3×3 For Production Web Apps?](http://rubykaigi.org/2017/presentations/codefolio.html)

これはVASILYさん的には面白いかと思います。
Ruby 3で3倍早くなったかどうかを確認するためのベンチマークの話です。
早くなったことを検証するためには、いいベンチマークがないと意味がないんですよね。
マイクロベンチマークでは3倍になったけど、実際のアプリケーションでは5％しか早くなっていないみたいなのはよくありますよね（笑）。
でも、かといって、ものすごい複雑なベンチマークだと検証が大変ですよね。
そうならないように、ちょうど良いベンチマークを作るように彼に依頼を出しています。

## Hanami - New Ruby Web Framework
[Hanami - New Ruby Web Framework](http://rubykaigi.org/2017/presentations/anton_davydov.html)

午後の休憩後にはHanamiの話がありますね。
Ruby on Railsに対するアンチテーゼで新しいフレームワークはこんな感じだよという発表かと思います。
まぁ、私自身はweb開発をしないんで、どちらが優れているかって聞かれてもよくわからないんですが（笑）。
こういうフレームワークもあるんだよという意味では面白いかもしれませんね。

## Development of Data Science Ecosystem for Ruby
[Development of Data Science Ecosystem for Ruby](http://rubykaigi.org/2017/presentations/mrkn.html)

あと、初日ではmrknさんの発表がオススメですね。
データサイエンティストがコーディングをするときにはPythonを使うことが多いと思うのですが、データサイエンスをRubyでやるにはどうやってやるのかの話をすると思います。
現状では3つのアプローチがあるんですが、そのうちの1つであるRubyからPythonの関数を呼ぶ方法の話です。

ちなみに残りの2つはSciRubyとApacheArrowですね。
SciRubyはSciPyやNumPyをRubyで実装するというアプローチです。
3つの中で1番筋は良さそうなんですが、いばらの道ですね。
というのも、Pythonの方が先を走っているので、追いつくためにはPythonよりも早く走らなければならないんです。
ですが、Python側の方が開発者は多いんですよね。
とはいえ、頑張っている人たちもいます。
最後のApacheArrowはプログラミング言語間でデータをやり取りするためのフォーマットです。
ファイルのフォーマットとメモリのフォーマットの両方があります。
計算処理はPythonにやらせてApacheArrow形式で書き出しておくと、Rubyで読むことができます。
いちいちファイルに書き出して、Ruby側でトラバースすると遅いのでそういうコストがなくて早いと思います。
あと、列指向なので、データサイエンスの分野での効率が良いとも聞いています。

# 2日目
## Progress of Ruby/Numo: Numerical Computing for Ruby
[Progress of Ruby/Numo: Numerical Computing for Ruby](http://rubykaigi.org/2017/presentations/masa16tanaka.html)

さっきの話の2つ目のアプローチを採っているのがNumoですね。
数値を効率的に扱うことができるデータ構造です。
いばらの道を頑張っている人です。

## Type Checking Ruby Programs with Annotations
[Type Checking Ruby Programs with Annotations](http://rubykaigi.org/2017/presentations/soutaro.html)

この発表も面白いと思います。
発表者の松本宗太郎さんは博士論文でRubyに型をつけるための研究をした人ですね。
結果的にはうまくいかなかったんですが、TypeAnnotationをつけて頑張ろうっていうのを余暇でやっているらしく、その発表をしてくれます。
Ruby 3で導入しようとしている型システムは型推論だけでどうにかしようというアプローチなんですが、それとは別のアプローチですね。

## Automated Type Contracts Generation for Ruby
[Automated Type Contracts Generation for Ruby](http://rubykaigi.org/2017/presentations/rubymine.html)

これも型に関する発表ですね。
Ruby 3とは違うアプローチで型をつけようとしています。
2010年代のプログラミング言語は型ありなのが当たり前になってきているので、Rubyはだいぶ置いてけぼり感（笑）があります。
ですので、コミュニティ内での危機感も高いと思います。

## Ruby Language Server
[Ruby Language Server](http://rubykaigi.org/2017/presentations/mtsmfm.html)

Ruby Language Serverに関する発表もありますね。
LanguageServerっていうのはエディターと通信して、リアルタイム構文解析やコード補完の機能を提供するものです。
もともと、コンパイラとエディタは独立しているので、IDEとかは内部的にコードを解析してエラーが出た時にはポップアップを出しますよね。
そういう機能を任意の言語でできるようにするのがLanguage Serverです。
これに対応するとLanguage Serverプロトコルに対応しているあらゆるエディタでコード補完が使えるようになります。
開発効率アップの可能性がありますね。

# 3日目

## Compacting GC in MRI
[Compacting GC in MRI](http://rubykaigi.org/2017/presentations/tenderlove.html)
この発表ではRubyのGCの話をするんですが、RubyのGCってCompactionしないんですよね。
Cのスタックでは数値であるかポインタであるかの情報を持っていないので、そこから参照されているオブジェクトを動かすことができないんですよ。
でも、Rubyのオブジェクトからしか参照されていないオブジェクトだったらこの問題が発生しないので動かせるという発想ですね。
Compactionによってより省メモリになる可能性があります。

## Bundler 2
[Bundler 2](http://rubykaigi.org/2017/presentations/0xColby.html)

あと、私は使わないけど、bundlerの話もいいかもね。
近いうちにbundlerが標準Rubyに組み込まれることが決まりました。
実はRubyGemsがbundlerに依存するという話が先に出たんです。
そうなるとbundlerも標準Rubyにバンドルするしかないという感じで決まりました（笑）。

# まとめ
Rubyの開発者であるMatzさんに今年のRubyKaigiでのオススメな発表を伺いました。
どの発表も興味深い内容なので、RubyKaigiが待ち遠しいです。