RubyKaigi 2022 09/08(初日) 参加レポート

# はじめに

RubyKaigi 2022に参加してきましたのでそのレポートです。

[RubyKaigi 2022](https://rubykaigi.org/2022/)

# Event

RubyKaigiではKeynote以外のイベントがありました。多くの企業の協賛やノベルティを配っていました。

[https://rubykaigi.org/2022/events/](https://rubykaigi.org/2022/events/)

![Screenshot_20220908-092014.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/b4ddf1b8-5145-69d7-8fba-c318d97fa804.png)

# Today’s Schedule

![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/1fd11843-363a-2aea-869f-5897414a54a2.png)

# Keynote Ruby meets WebAssembly

[Ruby meets WebAssembly](https://rubykaigi.org/2022/presentations/kateinoigakukun.html#day1)

URL: [https://speakerdeck.com/kateinoigakukun/ruby-meets-webassembly](https://speakerdeck.com/kateinoigakukun/ruby-meets-webassembly)

### Rubyの良さ

- 書いていて楽しい
- 何でも作れる
- エコシステムが成熟している

### Rubyの難しさ

- Ruby interpreterが必要になる
- ちょっとしたプログラムでサーバで動かしたくない
- RubyのInstall buttleがあり、環境によって動かない

### この難しさを解消するには？？

- 選択肢としてはWeb Assemblyがある
    - プログラムのゲームチェンジャー
    - Webブラウザでプログラムを動かせる
    - 外部の信頼できるプログラムであること
- ブラウザはどこでもあるからRubyはどこでも動く
- ブラウザ上で動けば環境構築で躓くことは少ない

### Execution Flow of WebAssembly

![Untitled 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/088b0148-a2c3-88bd-7d92-1c05c0b430c3.png)

### Demo

Rubyがブラウザで動く！！

JSとRubyが共存できる

> example
> 

```html
<script type='text/ruby'>
	document = JS.document[:hoge]
</script>
```

[https://github.com/ruby/ruby.wasm](https://github.com/ruby/ruby.wasm)

![PXL_20220908_021014845.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/c8b5d1cd-a281-abce-7841-31ba0a87a78e.jpeg)

[https://irb-wasm.vercel.app/](https://irb-wasm.vercel.app/)

### How WebAssembly works??

![Untitled 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/9702867a-1808-d344-40e2-fe932c6bffef.png)


### WASI (WebAssembly Sxxxx Interface )

様々な言語で動き急速に対応言語が拡大している

### Demo 2

Rubyがedge computeで動く！

https://github.com/kateinoigakukun/ruby-compute-runtime

### つまり

AsyncifyによってCRubyが動くようになった

### できないこと

- Thread APIがまだ動かない
    - WASI自体のThread APIが未定義のため `Not Implemented Error`になる
- C Libraryがまだリンクしていない
    - まだサポートしていない

### バイナリサイズ

8MB ~ 25MB

![Untitled 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/ba4ba83e-dcb1-ac36-d679-3a0f95dfef13.png)

### どのくらい早いの？

Opalが一番はやい、mrubyは、、、

![Untitled 4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/0ab58aa7-c19d-ff83-6d5b-27e6caf1ebdc.png)


### 試せるの？

[https://irb-wasm.vercel.app/](https://irb-wasm.vercel.app/) でかんたんに動かせる！！

# Making *MaNy* threads on Ruby

[Making *MaNy* threads on Ruby](https://rubykaigi.org/2022/presentations/ko1.html#day1)

[https://atdot.net/~ko1/activities/2022_rubykaigi2022.pdf](https://atdot.net/~ko1/activities/2022_rubykaigi2022.pdf)

## 何の話？

- RubyにMNスレッドをつくるという話
    - MaNy Project
- RubyにManyスレッドを実現する（>100K）
- 結局Golangみたいなものができた

## 例えば

CPUが3つあったときに、1つ1つRubyが取り合いになる (Ruby ~ 1.8 1:N)

Ruby 1.9 ~ 1:1

Golang M:N

## つまりM:Nはいい感じらしい

Rubyはまだだが

Golang gorutine, Rust, Java の機能提案がある

RactorはRactor間のスレッドは同時に処理できる

純粋なRubyはスレッドを単純に使うとボトルネックがある

## Blocking Operationはどうするの？（RDB connectとか）

そもそも止まってしまう処理がある

- Sleeping
- I/O Read
- RDB connect

## 課題

- 互換性があるかどうか
    - C Extensionで最初から1:1で組まれている機能
    - そもそもそれは Dedicated Native Thread (DNT, ロックするスレッド) でやる

### 欠点

- 互換性
- Overhead

## 面白いこと

- orderの話
    - 少ない前提、全スレッドいてレートする、数十万あるとボトルネックになる

## 評価

100万個以上作るとサチった

速度はMNのほうが早かった、想像の100倍とかではなかった

![PXL_20220908_045205030.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/f2fcf132-4ef2-fc92-330e-1192babfa7ff.jpeg)

![PXL_20220908_045250620.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/e4fa6f7f-a8f9-a925-f78e-116c1faee120.jpeg)

## Chat Serverをつくるとすると

### 真っ当にやったパターン

![Untitled 5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/c1628976-b05a-03b7-0b17-feb160214d4a.png)

### Queue パターン

![Untitled 6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/895b5d65-02b9-90e5-bfc7-813e4b3adf1d.png)

### Blockerパターン

![Untitled 7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/d8766fc3-b6d9-ff46-2878-dcd82337405d.png)

## これから

- 実行がまだまだ
- Ractorのサポート
- Ruby 3.2に入るかどうか。。。
- デバッガーをしやすくする(Massive concurrent application)

# Types teaches success, what will we do?

[Types teaches success, what will we do?](https://rubykaigi.org/2022/presentations/fugakkbn.html#day1)

## Talker

@fugakkbn

## Ruby の型を使ってる人は？

会場の1％くらいだった

## TypeScriptの型を使ってる人は？

会場の80％くらい

## Steep

型定義がLogicは別でできる

## なぜ普及しないのか

全体のGemの0.02%くらいしか普及していない

## Let’s contribute gem_rbs_collection!!

書き方はこちら

https://github.com/ruby/rbs

## 修正までのSteps

1. Finding
    - steep check
        - rbsファイルを静的に解析して実装と差異がないかチェックする
2. Check
3. Fix
4. Patch

## 型を作る手段

- 自動的に型定義をつくる
- 手動でつくる

## すべてのAPIの型定義を書く必要はない

- 実際に使われているもの
- 利用頻度の高いもの

## Generateの仕方

- rbs prototype rb \
    - gems/hoge/hoge/**.rb \
    - >> destination_file-generated.rbs
- 実行すると500行文のコードが生成される
- 大体は `Untyped`になる

### 全部にテスト書く必要あるのか？

- 全て書く必要はない
- 必要なものだけ、よく使われているものだけ
    - ⇒ でもそれでは誰も書かないのでは？

## 手動と自動はどんなふうに使い分ければよいのか？？

- 特定のAPIを実装するときは**手動**
- ライブラリ追加などで怒られたときは**自動生成**

## Finally…

rbsやSteepを積極的に使いましょう！

型もつけることでRuby本来の書きやすさを目指していきましょう

# Tools for Providing rich user experience in debugger

[Tools for Providing rich user experience in debugger](https://rubykaigi.org/2022/presentations/ono-max.html#day1)

[ono-max - Overview](https://github.com/ono-max)

## 何の話？

デバッガーのリッチなDeveloper Experieceを向上させる話

## やってること

- debug.gem (3.1~)
    
    [https://github.com/ruby/debug](https://github.com/ruby/debug)
    
- Ruby Programでデバッガーが使える
- VSCodeでデバッグをサポートできる機能の作成

## Chrome dev tools

- JavaScriptでデバッグできる
- これをRuby Programでデバッグできるようにした

## リッチなUIを使ってデバッグしたいけどVSCodeではない

VSCodeでできることをChrome dev toolsでできるようにした

## Demo

ChromeでRubyプログラムが動いてデバッグできる！！

- Step in
- Step over
- Step out
- Break point
- Call stack
- Chrome console ⇒ 使われそう
    - デバッグ中の変数を確認できる（あくまでRuby Program）
    - 変更もできる

Step Over, Break pointが一番使われそう

ローカル変数、return値が出てデバッグが可能

## VSCodeのデバッグについて

実行の順番や処理を記録したり、戻ることができる

Option

- back: コマ送りで戻れる
- forward: コマ送りで進める
- filter機能がある（History Inspector）
- Debug console
    - ActiveRecordのインスタンスでも見れる
    - Record検索時のURLをクリックするとVSCodeで良い感じに見れる
    - グラフ機能もある！

## 感想

RubyMineはまだなのかな？

確かに便利だと思うけど、もともとなかったのかという発見

# Towards Ruby 4 JIT

## 何の話？

- YJITについて話す
    - Shopify開発のJITコンパイラ
    
    [Ruby 3.1正式リリース。Shopify開発のJITコンパイラ「YJIT」をメインラインにマージ](https://www.publickey1.jp/blog/22/ruby_31shopifyjityjit.html)
    
![PXL_20220908_065357946.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134845/d01363fa-2937-3d23-e745-b60c8864a16d.jpeg)


- YJIT since Ruby 3.1~
    - 3.1 no code GC, C
    - 3.2 arm64 support , Rust, code gGC
- MJIT since Ruby 2.6~
    - 3.1 native threads, C
    - 3.2 Experimental, Ruby

## BYOJ Bring Your Own JIT

- Load and pause MJIT
- Define RubyVM::MJIT.compile
- Call RubyVM::MJIT.resume to start JIT

## Handling Benchmarks

- Benchmark
    - activerecord, hexapdf, liquid-render, mail…
- Other
    - binarytrees, erubi
- Micro Benchmarks

## My wish Ruby 4JIT

- Java, JavaScriptに近づけていきたい
- Pythonからは離れる
- 4年以内にPythonより5倍早くならなければ！

## How can we get there??

1. Constants
2. Variables
3. Method calls
4. Garbage collection

# 初日の感想

去年はオンラインだったのでだいぶわいわいしていていろんなRubyエンジニア、スポンサーブースの人たちと話せて楽しかったです。

Rubyはマルチスレッドや型付けなど今流行の言語の良いところを吸収していて5年後でも普通に保守性も高い言語として運用されそうだなと考えてます。

ただ今は初期生産性が高くて保守性はどうなんだろうと行ったところです。型付けがデフォルトになったRuby 3.1をみんなが使ってるところを想像すると楽しみですね。