「信条として一番重要なのは“開発者のモチベーション”」　ボトムアップで改善を進める、Rubyコミュニティ

最近おもしろいと思っている言語は「Erg」

司会者：mrknというRubyに詳しそうな方から、まつもとさんに質問です。「最近おもしろいと思っている新しいプログラミング言語はありますか？」

まつもとゆきひろ氏（以下、まつもと）：「Erg」という名前のプログラミング言語を作っている人がいて、これはPythonへのトランスパイラーなんですけど、言語そのものはPythonと似ても似つかない感じで非常におもしろいですね。

広く使われるかどうかはちょっと自信がないんだけれども、いろいろなおもしろいアイデアが詰まっているので、最近はそのリファレンスマニュアルを読むのが楽しみで、少しずつ読み進めていますね。

実際にソースコードもあって、ソースコードはRustで書いてあるんですが、実際の言語は、まだできていない機能がリファレンスにはすでに書いてあったりするので、そういう意味でおもしろい感じではあります。夢のある言語ですね、Erg、「エルグ」と読むんですかね。

フィーチャーリクエストを選択する時の基準は？

司会者：はい、ほかに質問ある方はどんどんどうぞ。

おっ、質問が来た。「ボトムアップでRubyが改善されているとのことですが、ユーザーからのFeature Requestsを取捨選択する基準はありますか？」

まつもと：そうですね、2つあって、1つは既存の部分。Rubyはけっこうでかいので、既存の部分との間の整合性というんですかね、矛盾みたいなものがあるかどうかというのが1つですね。

2番目は、たぶんメソッド名、あるいは文法が増えるので、それに対して適切なノーテーション……なんて言うの、見栄えや名前がきちんとついているかというところの2点が基準になります。

司会者：2点ってビシッとスラスラ言えるのはさすがですね。ありがとうございます。

ASTの前段になるパーザーはなんとかしたい

司会者：次、「以前のお話で、ASTクラスを公開したのはツールのためというお話だったかと思うのですが、今後、機能強化をする予定はありますか？」

まつもと：ASTの機能強化の予定は、今のところはないんですが。ただ、ASTの前段になるパーザーについてはなんとかしたいなと思っています。というのも、今のRubyのパーザーとそれの派生、「Ripper」とか「Parser gem」とかって完全なRubyのプログラムしか解釈できないんですよね。

なんだけど、例えばLSPとかを作ろうとすると、書きかけのプログラムでここまでパーズして、あとはまだまだエラーですみたいなところも、ある程度パーズしたいわけですよ。エラートレラントというんですけども。

そういう感じのパーザーを作るのを支援したいなという話はあって、具体的には明日話をするケビン・ニュートンが手を挙げてくれているので、彼の仕事がパーザーの改善のベースになるんじゃないかなと思います。

司会者：とのことです。ご質問ありがとうございます。

syntax_suggestの今後

司会者：次、Colbyから、「What's your favourite new default gem in Ruby 3.2 and why is it syntax_suggest？」。これは、Colbyが代筆してくれているけれども、syntax_suggest gemのオーサーからの質問です。

まつもと：syntax_suggestですって（笑）。いや、でもね、もしかしたらRubyのパーザーが、今度のケビン・ニュートンのパーザーで改善されたら、syntax_suggest相当は、実はビルトインになるかもしれないなとは思っています。でも今は、syntax_suggest、すごくいいよねと。

司会者：syntax_suggestが何かというと、2021年の「RubyKaigi Takeout」で発表してくれた、dead_endというgemが。

まつもと：リチャード・シュニーマンのdead_endの発表がおもしろすぎて、本質的なところが頭に入らないっていう欠点があったんだけど（笑）。

司会者：彼、本当にプレゼンが最高ですよね。

まつもと：最高だけど、おもしろすぎるよね。

信条として一番大事にしているのは開発者のモチベーション

司会者：はい、次の質問です、「Rustは、Matz' Ruby Implementationに入るのでしょうか？」。「入るのでしょうか？」というのはどういう意味だ？　じゃあ、RustがMRIのビルドスタックに入ったことについて、葛藤などがあったのであれば教えてください。

まつもと：ちょっと話したのもあるのですが、CRuby全体をRustで置き換えてRustRubyにするかみたいな話はぜんぜんないです。やはりRubyの本質的な部分である、RubyとCで実装するというポリシーは変更ないです。

ただ、オプショナルな部分について、今回はYJITでしたが、ほかの例えば、Bundler gemとかの実装にRustが入ることはあり得るとは思っています。だけど、コアの部分に関してはCのまま、そこは変わらない感じです。

司会者：個人的になんか嫌だなとかは思わなかったんですか？　「Rustかよ」みたいな「C書けよ」とか。

まつもと：私個人の信条として一番大事なのは、開発者のモチベーションだと思うんですね。例えばまつもとの好みで、「開発される言語、Rustは絶対ダメ」って言われるのは、だいぶモチベが下がるという可能性を考えた結果、コアじゃない部分については許容したほうが、トータルの開発の速度が上がるんじゃないかなと思って許可しました。

司会者：なるほど、ありがとうございます。

LSPの拡充以外で足りないと思っているツールは？

司会者：質問があるので続けますね。「LSPの拡充以外で足りないと思っているツールってありますか？」

まつもと：足りないと思っているツール。どうだろうな……。いや、すぐには思いつかないんだけど、「TypeProf」と「Steep」あたりで、もっと強化できる余地はないんだろうかって思うところもあるんだけど。

あとは、そうですね。個人的には、RuboCopのルールを選ぶのがタルいので（笑）、あなたのプロジェクトに対して最適なCopの集合を教えてくれるツールとかあるとうれしいなって思っていますけど（笑）。

個人的には、私の趣味に合わないルールがけっこうたくさんあるんですよね。そういうのは全部オフにしたいんだけど（笑）。だけど、ぜんぜんないのも嫌だというのもあって、そのへんのバランスを取るツールがちょうどあるといいなと思っています。もしかしたらStandard gemもそうなるのかなと思ったんだけど……それでいいのかな、ごめんなさい、歯切れが悪くて。

司会者：あくまで個人の意見です、というかたちで「MatzCop」をパブリッシュするというのはどうですか？

まつもと：確かに、そういう手もあるかもしれない。「これ、これ、これをオンにするやつが好きです」とか？

司会者：でも、RuboCopの設定を全部読まなきゃいけないですからね、なんとかCopの挙動とか、すごく膨大なので。

まつもと：一番簡単なのは全部オンにする。なんだけどそうすると、ここは僕は気にしないのにというところまでなんかすごく怒られるんだよね（笑）。でも、全部オフにすると意味ないしという感じですね。

司会者：そろそろいい時間なので、今日の最終コマ「Ruby Committers vs The World」でも、まつもとさんにいろいろぶつけるチャンスがあるかと。

まつもと：ぶつけられるんだ（笑）。

司会者：なので、いったん朝のセッションはここまでにしたいと思います。ありがとうございました、まつもとさん。

まつもと：ありがとうございました。

（会場拍手）