PR

そのあたりは軽量Rubyのコミュニティが形成されて、開発がどこまでドライブされるか次第であると。

 そういうことです。

ちなみにフルになってしまうと、本家のCRubyに限りなく近づいていくことになるのでしょうか。

 仮にmrubyでフルのライブラリが出来上がってしまうのであれば、割とかち合う可能性はあるでしょう。

 ただ、mrubyには(扱える)プログラムのサイズにもいろいろと制限があります。他のアプリへの組み込み用途を狙っていますので、プログラムもそれほど大きくはならないだろうとの読みがありました。ですので、あまり複雑なプログラムだと、(実行環境が)「複雑すぎます」とギブアップするケースも現時点であったりします。

 そうしたmrubyの制限や制約について踏まえると、純粋にmrubyが現在のMRI CRuby1.9の代替になるとは考えにくいと思います。可能性はゼロとは思いませんが、主眼ではないですね。

Rubyはメソッドの豊富さが一つの特徴かと思いますが、今のmrubyは実装済みのメソッドがまだ少ないという声があります。

軽量版のmrubyを開発したまつもと氏(写真:新関 雅士)
軽量版のmrubyを開発したまつもと氏(写真:新関 雅士)
[画像のクリックで拡大表示]

 「これがないと他の機能が提供できません」という類いのものは我々で作りますが、足りないメソッドは使い手の方々に補っていただければと思っています。

 今のmrubyが提供しているメソッドも、かなりの割合でRuby言語で実装されたものがあります。Rubyで記述し、それをmrubyのバイト・コードに変えて、mruby(の実行環境)に一緒にリンクして提供している。そうしたメソッドも多くあります。

軽量Rubyのプロジェクト側で100%すべてのメソッドを実装して提供するということではなく、「コアの部分は作りました。ライブラリなど後の部分は皆さん、自分で作って自由に使ってください」と。

 そうですね。本家CRubyのMRIとmrubyの大きな違いというのは、MRIの場合は「出来上がったインタプリタが一つありますと。これを使って皆さん、プログラム作って下さい」というのが基本的なスタンスです。

 一方、mrubyの場合は、「ここにmrubyという素材があります。これを使ってあなたのアプリの中でどうぞ使って下さい」というスタンスです。ですので、「どこまであればいい」という明確な境界もない。逆に「大きすぎるとメモリを食い過ぎて嫌だ」という人もいるわけです。そのあたりを使い手が自由に選べるよう、素材の状態で提供しましょうというのがmrubyの考え方です。

 mrubyがデフォルトで提供するものは、一般の技術者の方が実装しようと思っても簡単には作れない部分です。そこをコアとして提供しましょうと。

 例えば、一般的な組み込みソフトウエア技術者が「次のプロジェクトはRubyでやる。だからRubyのVMを作れ」と突然上司から言われても、なかなか難しい面があるでしょう。その部分はオープンソースとして提供します。

 逆に「このメソッドが足りない」という部分については、(C言語ではなくRuby言語でも実装できるのですから)自分でやっていただく方がいいのではないか、との判断です。