オライリー・ネットワークにM. David Peterson氏が最近掲載した「Ruby.NET vs. IronRuby：その違い」という題名の記事が、マイクロソフトで IronRuby プロジェクトのリーダーを務めているJohn Lam氏の注意を引いた。John氏は IronRuby に関して彼自身の手で説明し、Davidの記事につけ加えている。
David氏の記事は Ruby.NETとIronRubyの相違を指摘することを目的としている。David氏はIronRubyについて次のように述べている。
* 静的型つき言語（C#など）と動的型つき言語（Rubyなど）間の特定の相違をサポートするために調整された CLRの延長である動的言語ランタイム（DLR）上に構築されているのが、IronRuby です。
Ruby.NETについては、こう述べている。
*Ruby.NETはCLRの上に構築されます。DLRがCLRの延長であるため（つまりDLRはCLRを必要とする）、IronRubyの能力とRuby.NETの能力には基本的な違いはありません。
John氏はDLRをターゲットとする言語にはDLRのメリットがあると説明する。
- 共有コード生成エンジン。我々のコード生成API はReflection.Emit を使用するよりずっと簡単なため、コンパイラ作成者は時間を節約できます。これはまた、将来DLRのパフォーマンス改良があれば、DLRをターゲットにしたお気に入りのプログラミング言語に無料で利用できることを意味します。
- 共有ホスティング・インタフェース。 我々はホストとプログラミング言語間のブローカー的役割を果たします。DLRをターゲットにすれば、我々のプログラミング言語（そして我々の作成ではなくともDLRをターゲットにした言語）は、余分な労力を払わずともうまく働きます。私のチームではSilverlightとASP.NETの両方を対象にホストを構築しています。
腑に落ちないのは、CLRによってデベロッパがあらゆる共通中間言語（CIL）を遵守する言語にアクセスできるのであれば、なぜわざわざDLRをターゲットにするのか、ということである。もしそうなら、IronRubyよりRuby.NETを選ぶのが筋だろう。
David氏の元々の疑問はこうだ。
私が求めているのは、CLRが提供するより広いベースの言語間で interopの増加でしょうか（従って Ruby.NETを使用）、それともDLRによるパフォーマンス・ゲインでしょうか（従ってIronRubyを使用）？
John氏が自分の見解を説明して応答する。
既存のCLRベース言語のinteropに関しては、DLRをターゲットにすることによって失うものは何もありません。既存のCLRベース言語（C#もしくはVB.NETからのOffice APIを呼び出した方が良いでしょうか）で動的ディスパッチの改良点が多数あることは確かに真実ですが、C#からのIronRubyライブラリ・コードの呼び出しを阻止するものは、今日存在しません。我々のホスティング・インタフェース［1］を介して呼び出しを行う限り、問題なく動作するはずです。Rubyのような言語が要求するコンテキストの諸々全部を渡さずに、C#から任意のRuby.Netコードを呼び出すことがなぜ可能なのか、私にはよくわかりません。
David氏はこうも言っている。
動的にコンパイルされたIronRubyの特質は、予測が非常につきにくいクライアント側アプリケーションの世界に適し、静的にコンパイルされたRuby.NETの特質は、より予測しやすいサーバー側アプリケーションの世界に適します。
John氏が以下のように応える。
静的コンパイルモデルであるRuby.NETの主なメリットは、コールドスタート時間を最小にとどめることです。Ruby.NETではアッセンブリをJITさせなければならないため、CLRのコールドスタートにさらに対処しなければなりませんが、一方IronRubyではILを生成し、「さらに」コードをJITする必要があります。ですから、私はこの議論の方向を変え、コールドスタート時間が非常に重要なクライアントアプリケーションではRuby.NETに利点があると申しましょう。そうは言っても、IronPython向けのAOTコンパイルモデルというものがかつて存在しましたが、その後DLR 1.0の機能リストから削除してしまいました。バージョン1.0以降で再考したい点です。
John Lam氏によるコメント投稿以降、David氏は元の記事に修正を加えたが、まだ返答されていない質問が若干残っている。現在のRubyデベロッパが知りたいと思っているRuby.NETとIronRubyの一側面は、Ruby on Railsがこのどちらかのプラットホーム上で動作するようになる時期である。Ruby.NET陣営のあるデベロッパは、Ruby.NET上でRuby on Railsを走らせようと考える以前に、Ruby実装で開発を要する5、6個の重要な構成要素が存在することを示唆した。IronRubyでRuby on Railsが動作するようになるか否か、またその時期に関する具体的な情報はないが、John Lam氏がRubyConfで今年と示唆していた。
Seo Sanghyeon氏(ブログ・英語)によると、Rubyと.NETをすぐに統合させる一番簡単な方法は、John Lamが行うプロジェクトのRubyCLRを用いることである。
IronRuby、Ruby.NET、RubyCLRから選択する際に考慮するべき問題は多々あり、こうしたプロジェクトは初期段階にあるので、.NETプラットホーム上でRubyのコードを書きたいのなら、IronRuby、Ruby.NET、RubyCLRから目を離さないことである。
IronRubyについての追加情報はIronRubyのWebサイト(サイト・英語)で見つけることができるし、John Lam氏のブログ(ブログ・英語)も追い続けよう。