Discussion
Closed
将来の Ruby にあったいいなと思うもの（機能・特徴などなど）を教えてください。
文法的なことでも，クラスやライブラリーでも，周辺ツール，あるいはドキュメントやコミュニティーに関することでもかまいません。
ただし，現在話題になっていないもの限定です。
例えば「何らかの意味での静的型付け」や「並行実行の仕組み」は Ruby 3 に向けてまさに実装が行われています。
漠然とした「高速化」も大昔から言われており，現在もたいへんな努力が続けられています。
これらは実際，話題にもなっているので除外します。
ただ，「話題になっている」と感じるかどうかは主観も入りますし，自分の目の届かないところで話題になっていても知りようがないので，ご自分が「話題になってない」と思うならそれでいいことにします。
Scalaのアクセス限定子的なものがあると嬉しいなぁと思っています。
今のprivateやprotectedだけでは特定のクラスにだけメソッドを公開したい、みたいなときに実現するのが難しいので、結局コメントやraiseを使ってがんばるような実装になってしまうことが多いです...
もうちょっとスマートにやれるといいなぁとよく思います。
@ycv57u6y さん
なるほど。
現状だと，あるバージョン（たとえば 2.7）で主にどんな変化があったかは
あたりが，日本語情報では頼りになりますが，新機能などが全て載っているわけではないし，「あるメソッドがどのバージョンから使えるのか」を調べるのは大変ですよね。
Enumerable#sum とかだと，Ruby 2.7 の
https://docs.ruby-lang.org/ja/2.7.0/method/Enumerable/i/sum.html
を開いておいて，URL の「2.7.0」を「2.6.0」→「2.5.0」→ と順に減らして，「2.3.0」まで行ったら「Not Found」が出るので，「おお！ Ruby 2.4 からだったか！」と判ったり 
@getty104 さん
特定のクラスにだけメソッドを公開したい
おお！ 考えたこともありませんでした。
もしよろしかったら Scala のアクセス限定子について，Scala を知らない Ruby 使い向けにちょこっと説明していただけませんか。
@scivola
https://qiita.com/himarin269/items/619afe9eef0b66769a32#%E6%AF%94%E8%BC%83%E8%A1%A8
↑みたいな感じで、privateやprotectedに加えてホワイトリスト的にアクセスを許可するパッケージやクラスを指定できるような修飾子です！
これを用いることで特定のクラスでこのメソッドは用いたいが外部公開はしたくない、みたいなときに宣言的にそれを記述できていいなと思っています。
Ruby の変更点の完全な網羅を目指した非公式ドキュメントとしては Ruby Changes があります。2.4以降の新機能はここを見れば分かるんですが……やっぱり個々のメソッドの Availability は公式リファレンスにほしいですねえ。
Web では リファレンスマニュアル にお世話になりますが、例えば Apple Developer Documentation にあるような Availability（iOS 13.0+, macOS 10.15+）のように、どのバージョンから使えるクラス・メソッドなのかといった情報が欲しいです。毎年クリスマスのリリースノートである程度は把握できますけどね。
私も以前からほしいなと思っていたので、Issueを立ててみました。
https://github.com/rurema/bitclust/issues/132
@getty104 さん
なるほど，Scala のアクセス限定子，面白そう。
「みんなの欲しいもの教えて」と尋ねる人はたいがい自分の欲しいものを訊いてもらいたいものだけど，私も例外ではありません。
たくさんあるけど，まずは「親切なエラーメッセージ」。
以前「Ruby のエラーメッセージを読み解く（初心者向け）その 1 - Qiita」なんて記事を書きましたが，その中で触れたように
syntax error, unexpected end-of-input, expecting keyword_end
なんてエラーメッセージに出てくる end-of-input だの keyword_end が何なのか，初心者には分かるわけないですよね。
リファレンスにも一切説明がありません。
keyword_end なんて，処理系のはらわたが表に出てきた印象を受けませんか。
以前，teratail で初心者の相談にのってて，とても多くの人がエラーメッセージを読み解くことができていないのを実感しました。
「エラーメッセージなんてそんなもんだよ」「こういうのがパッと分かるのが一人前なんだな」なんて思わないでほしい。
Rust コンパイラーのエラーメッセージの親切さは衝撃的。で，エラー番号で
rustc --explain E0499
すると一般的な解説が表示されるという。
エラーに関する情報源の乏しさもなんとかならないものですかね。たとえば syntax error にどんなものがあるか，その一覧すらリファレンスにありません。
それから，多言語化も実現してほしい。エラーメッセージは英語なのが当然なんて思わないでほしい。
なんてことを考えてたのですが，昨日，まったくの偶然で，eturem という gem を見つけました。
日本語解説はここ：
https://github.com/nodai2hITC/eturem/blob/master/README.ja.md
Ruby のエラーメッセージを、初心者にわかりやすく表示するための gem です。
Easy To Understand Ruby Error Message の略。
とあります。
まだ試用してませんが，おそらく私が望んでいたものと近い方向性なのだろうと思います。
そうだとすると，こういうものを Ruby 本体に組み込んでほしいのですよ。
で，この gem は私の知らないところで既に話題になっていました。
週刊Railsウォッチ（20200609後編）Rubyにカスタマイズ可能な軽量fiberスケジューラを実験導入、RailsとGraphQL、DBについて知って欲しいことほか｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社
しかも，いまこれを書きながら検索してたら，作者ご本人（@nodai2h_ITC さん）による Qiita の記事までありました！
Ruby のエラーメッセージをわかりやすく表示する gem「Eturem」を作った - Qiita
ん？ しかも私の記事に言及してくれてるやん？！ なんで気づかなかったんだろう？？？
競プロで使えるデータ構造やアルゴリズムの組み込みライブラリが欲しいです。
Red Chainer系のプロジェクトでRubyでデータサイエンスもやっていくというコミュニティの気概は感じましたが競プロへのアクセスは低く感じます。
Pythonはcsgraphやpriority queueなどの便利ライブラリが組み込みで利用できますがRubyは弱いです。
選考にそういった問題がある企業も多いので雑に言えば新たにRubyを覚えるよりPythonの方が就職に有利になっている気はします。
@hiromichinomata さん
なるほど。
「組み込みライブラリ」じゃなくても標準添付ライブラリー1にあればいいんですね。
csgraph がどういうものかは私には分かりませんが（ググっても分からなかった），priority queue なんかはあってもよさそうなのに無いんですよね。「ruby priority queue」で検索するといっぱい出てくるので，それなりに需要はあると思うんですが。
別途インストールする必要が無く，ただ require するだけで使えるライブラリー ↩
@scivola
そうですね。インストールするだけで入るライブラリーならそれでいいと思います。
Kaggleのカーネルならライブラリやバイナリファイルを直接アップロードして使えるようですが、AtCoderやTopCoderのような競技プログラミング業界ではあくまで1ファイルでの提出が標準に見えたので。
gemを仮に作った人がいても外部ライブラリを読み込めないという制約があると標準よりに入るライブラリの方が現状では使い勝手がいい気がします。プラットフォームとの交渉次第なのかもしれませんが。
csgraphは scipy.sparse.csgraph のことでした。要はAtCoderでPythonで競プロする限りにおいてダイクストラやベルマンフォード法があらかじめ用意された関数が使用可能ということで、自前でコピペスニペットを用意しないといけない言語はたとえ速度が同じでもその労力分不利ではあるということです。
https://note.nkmk.me/atcoder-python-numpy-scipy-version/
逆に Ruby にあるメソッドでいうと、repeated_permutation とかですよねえ。
これがあるとないとで労力が全然違う。
@hiromichinomata
AtCoderのPythonはnumpyもscipyもつけた親切Pythonのようですね。C++ではboostまで使えると至れり尽くせりのようです。
Rubyでもこの関係のデファクトスタンダードがあれば、要望出せば追加してくれそうな気がします。
この問いかけでは，漠然とした「高速化」は範囲外，としたのですが，Ruby の速度に関して私が「欲しい」と訴えたいことが二つあります。
一つは起動時間の短縮ですね。
なんか処理系が立ち上がるまでずいぶん時間がかかると思いませんか。
処理系に関して全くの素人なので，一体どこに時間がかかっているのかさっぱり分からないのですが，たとえば端末で
irb
って打ってからプロンプトが出るまで，私の MacBook Air（ということは SSD です）で 1 秒くらいかかります。
何か仕事やっててちょっと計算したくて，irb を電卓にしようとしてもこの 1 秒がストレスなんですよね。
ほかのマシンだと 2〜3 秒かかるときもざらにあります（同じ実行環境でもそのときどきで変わる）。
Ruby は Rake や Thor を使うと端末でやる定型の仕事が自動化できてものすごく便利なんですが，動き始めるまでに秒単位の時間がかかる，というのがかなりのマイナスです。
せっかくゴチャゴチャした処理を簡潔に記述する優れた記述力があるのに。
先日，いつもの Rake タスクの一つ（ごく簡単なもの）を Rust で書き直したらものすごく快適になりました。
実行に 30 秒かかる処理なら，起動に 2 秒かかっても気にしないんですけどね。
さて，高速化に関してもう一つの希望は，例外が発生したときの終了の速さです。
例外が発生したとき，実行が終わるまで何秒もかかったりしませんか？
これも仕組みを知らないのでなぜそんなに時間がかかるのか謎です。
（私がヘタレだということもありますが）バグのせいで例外が発生して，直したつもりが直せてなくてやっぱり例外が出ることがありますよね。
何度も何度も実行→例外→修正→実行→例外→修正・・・を繰り返しているとき，この例外から戻ってくる時間がストレスフルなんですよね。
なんか処理系が立ち上がるまでずいぶん時間がかかると思いませんか。
立ち上げの遅さは今のrequireとrubygemsの仕組みのミスマッチだと思います。
現在のRubyはrubygemsが標準になってますが、rubygemsが有効だと通常の$:にない場合は、Gemを探して$:に追加してrequireできるようになっています。問題は$:のリストが凄く多くなることがあると言うことです。適当なRailsアプリでrails cしたあと$:.sizeでもしてみますと、作ったばかりの状態でも100以上になります。そのような状態でrequireする時にどうなるかというと、$:記載のディレクトリ全てに対して順番に見に行くというすさまじいことが起きます。しかも、これは並列化ができないので、遅さに拍車をかけています。
ファイルの非存在確認というのはファイルシステムへの負担が大きいです。glusterfsという分散ファイルシステムがあるのですが、非存在確認というのがことのほか苦手で、通常のファイルシステムに比べて極めて遅いというものです。そのglusterfs上にrailsアプリを置いて起動してみたことがあるのですが、10分かかりました(ローカルの開発環境では1分もかからない)。起動さえしてみれば、ページ応答は普通で、ほとんど問題ないんですけどね。他にも、WSL(WSL2は試していない)等のファイルシステムが遅いシステムでは立ち上げの遅さにちょっとイライラする感じです。
rubygems経由のrequireは$:を使わずにそのパス指定で見に行くとか、そういった仕組みが必要だと思っています。rubygemsは便利ですし、それを利用したbundlerもとてもよくできた仕組みですが、ここら辺を高速化しないと、立ち上げ時の遅さ問題は解決できないのではないかなと思われます。
@raccy さん
興味深い話です。
そのとおりだとすると何かしら改善のしようが無いわけではなさそうな気もしますね。
本件は，私の狭い視野の中では話題になっているのを見たことがないので書きました。
Enumerable#each_with_indexが遅いのはどうにかしてほしいですね。
Array#each_with_indexおよびHash#each_with_indexが必要かと
あとは、組み合わせ計算や階乗なんかも欲しい時がありますね。
(Math.#lgammaでも悪くはないんですが、整数が欲しい)
@asm さん
組み合わせ計算というのは nCr とか nPr とかを計算するメソッドですか？
（いま TeX の形式で書いてみたら正しくレンダリングされなかった。なんでだ？）
早い遅いは別として、単純にインデックスが必要なだけならこれはどうでしょう？
https://docs.ruby-lang.org/ja/latest/method/Enumerator/i/with_index.html
{a: 1, b: 2}.each.with_index{|pair, index| p [pair, index]}
コミュニティー的に欲しいものは企業の支援ですね。
具体的な分野の第一はドキュメント。
公式リファレンスマニュアルは慢性的な人手不足です。少数のボランティアの方が尽力されていますがとても大変です1。
Ruby 開発者を雇用する形で Ruby を支援している企業はいくつもあるのに，ドキュメント編集者を雇用するとか業務でやっているとか聞いたことがありません。
処理系やライブラリーの開発と並ぶ重要な分野だと思うんですけどねえ。
ドキュメント以外にも地味だけど大事な分野はいくつかあると思います。
ボランティアの興味だけだとどうしても偏るので，そこを企業とかがカバーしてくれたらな。
私はちょっぴりだけ手伝っていますが，気まぐれにしかやっていません。 ↩
@hiromichinomata
作ってみたらいいと思いますね。
競技プログラミング用のライブラリを。
https://github.com/yoshoku/rumale
みたいなものを作れてしまえば、これほど強いアピールはないでしょう。
@scivola さん
拙作 eturem を目に留めていただきありがとうございます。あまりこのようなものは需要が無いかな…と思っていましたが、同じようなことを考えている方もいるとわかり安心しました。
せっかくなので便乗して質問させていただきますが、このエラーの時にはこのようなメッセージ・情報が表示されるとわかりやすくなるのではないか…というアイデアがあれば、どんどん取り込んでいきたいので教えていただけると幸いです。なお現状の eturem で表示されるメッセージ・情報については Qiita に書いた記事を書き足したので、もし良ければご覧いただければと思います。
ちなみに、「処理系のはらわた」と評された keyword_end ですが、2.7 以降？では ````end'``` になって少しはハラワタ感が減ったようです。
この記事の本題である「Ruby にほしいもの」も 1 つ書かせていただきます。（おそらく技術的に難しいでしょうが…）
普通 load 等で実行したスクリプトからは何だってできてしまいますが、「できることを制限した load」というのがあると面白いのではないかと考えています。
例えば、誰かが Ruby で「AI 部分のスクリプトを差し替え可能な将棋プログラム」を作ったとします。そうすれば将棋 AI のアイデアがある人は、AI スクリプトだけ書けばゲームロジックを作らなくても自分の AI 将棋を作成できます。ですが、悪意ある人間が「すごい強い AI 作ってみたから試してみて！」と言って PC 内のデータを全消去するようなスクリプトを公開した場合、騙されて実行してしまう人がいるでしょう。
そこで「できることを制限した load」というのがあれば、第三者が作ったスクリプトを実行することを想定したプログラムを安全に書けるようになり、Ruby の使い道が増えるのではないでしょうか。
@nodai2h_ITC さん
ちなみに、「処理系のはらわた」と評された keyword_end ですが、2.7 以降？では `end' になって少しはハラワタ感が減ったようです。
あ，ホントだ。
手元で試したところ，以下のようでした。
| バージョン | 表記 |
|---|---|
| Ruby 2.5.3 | keyword_end |
| Ruby 2.6.5 | end |
| Ruby 2.7.1 | `end' |
これを見ると，
「やっぱ keyword_end じゃ分かりにくいか，単に end だな」
「いや end だけだと制御構造の end だって分かりにくいぞ，引用符付けるか」
みたいな経緯なのかと空想（妄想？）されますね。
-w オプションで表示される警告メッセージも，以下のケースでは Ruby 2.7 で変更になったようです。
if e
else
end
Ruby 2.6.5 では，
5 行目の
'end'が 1 行目の'if'と合ってねえよ
ですが，Ruby 2.7.1 だと
5 行目の
'end'が 3 行目の'else'と合ってねえよ
でした。
こちらも，より近い else のほうを引き合いに出すことで問題の所在を分かりやすくする工夫だったのかな，と想像されますね。
エラーや警告のメッセージも改善が続いていたなんて，教えていただくまでぜんぜん気づいていませんでした。記事は修正しました。