本稿は，軽量Rubyを軸にしたソリューションのアーキテクトとして，私はこう考えました，ということを述べています．
設計思想に関する話です． 一つのシステムに対して，設計思想は幾通りもあるのが普通です． どの思想にも，一定の理があります．
読者が何かの拍子に，軽量Ruby系実装を選ぶことになった際に，参考になればと思います．
サブセットは滅びの道?
ムーアの法則は，まだしばらく正しい状態にあるでしょう．
つまり，市場シェアが高い(有り体にいうと開発資金のある)があるアーキテクチャには，まだまだ計算機資源が潤沢になる余地があります． 一方，市場シェアが低いアーキテクチャは，性能向上は伸び悩むでしょう．
別に特定のアーキテクチャを云々したいわけではありませんが，SuperH アーキテクチャは，一時期，動作クロック数をメキメキと上げていきました． 今は， ARM Cortex アーキテクチャがその状態のように見えます． PIC32 も，他の PIC アーキテクチャが援軍となっているのか，頑張っているようです．
それが，市場原理というものであります．
このようなメインストリームのアーキテクチャ(今なら Cotrtex)では，ソフトウェアの規模がどんどんと成長します． 多くの RTOS は API が枯れているはずなのですが，ドライバやミドルウェアが成長していきます． 本棚と本の関係と一緒で，計算機資源があるかぎり，ソフトウェアは膨張していきます．
一方，シェアの低いアーキテクチャとそのユーザは，その姿を脇に見て，歯ぎしりをして済ますわけにはいきません． 死活問題ですから． そのため，一部だけでも移植して，メインストリームが享受している生産性の，喩え一部でも得ようとします．
しかし，サブセットは，所詮サブセットです． シェアの低さをひっくり返すことはできず，そのうち，アーキテクチャが消えます． それが，市場原理というものであります．
動作環境がないソフトに価値はありません． せっかく作ったサブセットは，ビット世界のどこかに霧散します．
サブセットの全てが悪ではない
もちろん，成功する例もあります．
機器組み込み屋からWeb屋まで幅広く知られている例として sqlite があるでしょう． 他の SQL データベースからすれば，サブセットです． しかし，sqlite は，型が極端に少ない，ライブラリとして動作する，など，設計思想が他と一線を画しています．
mruby もまた，機器組み込み以外の分野で，一定の成功はしていると見てよいでしょう． mruby も他の Ruby 実装から見ればサブセットです． しかし，先行する Lua の VM 実装を研究し，他の Ruby 実装には無い特徴を有しています．
サブセットのアンチパターン
サブセットで危険なパターンというのがあります．
実装の一部を切り取ってきて，制約の多いアーキテクチャに移植する，というものです．
「8bit の PIC や AVR に uITRON のサブセットを頑張って実装する」というのは典型例の一つです．
アーキテクチャの制約のため，実装をサブセット化した，というものには，継続性に対するリスクがあります． 上記uTRONの例なら「16bit の使えばいいじゃん．値段変わらんよ」で存在価値は容易に0になりますから．
無論，全てのプロジェクトが失敗するとは限りません．
成功した一例として uClinux が挙げられるでしょう． これは，MMU サポートのない CPU のために Linux のサブセットを作る，というプロジェクトでした． uClinux の場合は，MMU をサポートしない CPU は，かなり長い期間存在する，という見切りの旨さがありました． MMU が無いという前提を立てる一方で，メモリ容量やクロック数には制約がかかっていません． それらは，MMU をサポートしない CPU であっても，性能向上が見込めるからでしょう． そして，実際に，ハイエンドマイコンでは，そうなっています．
今手元にあるチップのメモリやクロックに制約があるから，という理由でのサブセットは，徒労に終わります．中長期的に見て． (…って書くと呪いをかけているように思われるかもしれませんが．)
サブセット化はあとからでもできる．芯がしっかりしていれば
mruby のコミットログを見た人からは，
そうは言っても，あなた，mruby から stdio.h サポートを外したり，さんざサブセットにしてきたじゃないの
と言われるかもしれません．
ええ，その通りです． そして，まだ，本家 mruby にも，その fork である monami-ya.mrb にも，サブセット化の余地が残っています．
しかし，それらは，特定のアーキテクチャで動かしたいからという動機から来るものではありません． (C99標準が定める)freestanding 環境での実行を確約するためのものであったり，UARTすら用意できないという 機器組み込みシステムでは古今東西普遍的にあるシチュエーションへの対応だったりというものばかりです．
サブセット化をし易い “芯” を作っておくことは大事です． しかし，詰め込むことを先にするのは，リスクが高い． monami-ya.mrb での各種拡張を手掛ける際に，私は，そう考えて設計と実装を行いました．
サブセット実装には不思議な魔力はあるが
私も現役の組み込み屋ですから，「そうは言っても目の前の機器に組み込まないと成果にならないのよ」というお話は解ります． 案件ベースでは，サブセット実装をせざるを得ないでしょう．
そして，サブセット実装が持つ，得も知れぬ魔力が解らなくもないです． 私もガラパゴニッポンの組み込み業界で育ちましたので， 実装者として，純粋に，愉しい．不思議な魔力．
しかし，イマイマを乗り切るための方便と，この先何年か使われることを前提とした提案がどうあるべきか， 現在的実装がどうあるべきかというのは，分けて考える必要があるはずです．
なので，(サブセット実装の成果物である)最小サイズの追求を，当面の monami-ya.mrb では行わないのです．