先日のFoo Campにおいて、GoogleのSteve Yeggeが"GoogleのRailsクローン"という講演(John Lamによるレポートはこちら（source）)を行い、GoogleでRuby on Railsを移植した経験について語った。
Google における開発者の生産性を向上するための取り組みの中で、Steveはプログラミング言語としてRails(その結果としてRuby)を採用するよう説得を試みました。そして聞き入れてもらえない(Googleは実際、彼らのインフラがサポートしなければならない言語をこれ以上増やしたくないのです)と感じた時に、不満を感じたプログラマーが誰でもそうするように、SteveはRailsをJavaScriptに移植することを決めました。コツコツと。
これははっきりとソフトウェア開発コミュニティの興味を引き、あらゆる方面からの反応があった。この取り組みは他のいくつかのプロジェクトを想起させた。特にTrimPath Junction（source）や、他にはRuby on Rails in Javascript（source）の再現への試みだったり、Phobos（source）やHelma（source）なども同様である。多くはこれを、Yeggeによる「次の偉大な言語はJavascriptかECMAScriptである（source）」という主張の裏付けだと見なし、Marshmallow（source）やRich Programmer Food（source）といったSteveによる最近の投稿に言及した。 .NET on Railsとのつながりについて熟考する人もいれば（source）、こうした努力に対して疑問を投げかける人（source）もいた。そのため、Steveは彼のブログを更新して、さらに詳しく述べている（source）。
InfoQ はSteve Yeggeと話す機会を得た。彼は、その取り組みに対するいくつかの質問に対して親切に答えてくれたが、彼が話すことはGoogle全体についてではなく彼自身と彼の意見についてであり、これを読んだ人はGoogle全体としての結論についてのあらゆる深読みをすべきではない、と即座に指摘した。
何よりもまず、そのプロジェクトをどう導いていくのか、というありきたりな質問についてである。 この取り組みは公開されるのか、そしてオープンソース化されるのか、そしてそれが行われるとしたらいつなのか。Steveは、この件については将来的には語ることもあるだろうし、考慮することにもなるだろうが、すぐにそれが起きることはないだろう、と述べた。
我々は"Rhino on Rails"のオープンソース化について話をしましたが、今のところそれは単なる雑談以上のものではありません。理由の一つとしては、実際のアプリケーション開発における二次的な作業としてフレームワークの開発を行っているため、その進みは遅く、大体20%くらいの作業割合であるということが挙げられます。もう一つは、我々(のフレームワーク)は他のGoogleインフラストラクチャのコンポーネントに依存していますが、それら自身オープンソース化のプロセスを経ている最中であり、それらが発表されるのがいつなのか私はまだ知りません。
しかし実際一番の理由としては、JVM上のRails的なwebフレームワークで何が起こるかに注目している最中だということです。様々な成熟度の Railsクローンが存在しており、その中にはJRuby on Rails、Grails、Phobos、TrimPath、そして他にも恐らく半ダースぐらいの物が含まれています。
もし2、3年のうちに、これらのうちのひとつが有力なプレイヤーとして浮上してきて、セキュリティ、パフォーマンス、スケーラビリティ、国際化のサポート、などといったGoogleの内部的な品質基準を満たしていた場合、それに移行する可能性を考慮していないのは愚かなことでしょう。それ (Rhino on Rails)は恐らく巨大で、我々のチームから外部に出し、オープンソースとして世に出さなければ、たぶん見捨てられてしまうでしょう。しかし私は、どちらにしてもそうなってしまうということを何年も前から知っていると考えています。プラットフォームが成熟するには長い時間がかかり、そしてWebフレームワークの世界は現在非常に揺れ動いています。
従って、そのフレームワークに関するあらゆる外向けのリリースは、次の2、3年間のオープンソース市場の状況次第です。そしてまた、それがGoogleの内部でどう好意的に受け止まられるかにもよりますが、それはこの1年くらいの間ではわからないでしょう。
Railsについて、そしてRhino on Railsは'移植'なのか、Railsに着想を得た単純なフレームワークなのか、それともそうでないのかについては次のように述べている。
たまたまですが、私はRailsが何となく気になっていました。私はRailsとは関係なくRubyがとても好きでした。しかしWebページを作るには、 Railsは私が使ったことのある中で最も良いものです。そして我らがヒロインRailsや、彼女の森の静かな小動物達 - 他の言語で書かれた多くのRailsクローンは言うに及ばず、PrototypeやScriptaculousと言った親友たち - などに非常に多くの利用可能なタイトルがあることに驚かされました。私は、DHHがそれを作ったとき、真にユニークで重要な何かを知っていたのだ、と述べました。称賛に値します。
それは'移植'なのか、Railsに着想を得たJavascriptフレームワークなのか、については、
それは真の移植に近いものです。JavaScript言語の制約を受けてはいますし、ActionViewとActionControllerの部分[そしてRailities]だけで、ActionMailerは含まれません...あと、ActiveRecordのほんの一部です。しかし、現在制約を受けている中で最も大きな部分は、いかにしてバックエンドと対話するかについてです。長い間、私はその筋書きがHibernateによってなされるだろうと考えています。しかし、我々はそのフレームワークをRailsよりも良いパフォーマンス、セキュリティ、そしてi18nのサポートを得るところまでだんだんと拡張してきました。その3つはどれも等しく重要であり、またRailsの本は恐らくフレームワークを極める道程の60%程度しかカバーしていません...我々はまた、気の利いたデバッガや、EclipseとEmacsに対するIDEの機能を含む、いくつかの良質なツールサポートも構築しました。
彼がなぜ、Ruby on Railsを直接使わないのか、については、
プログラミング言語というのはちょっと変わった小さな猛獣のようで、100%飼いならしたシベリアンタイガーをペットに持つのにいくらか似ています。あなたは、それら二つととてもうまくやって行けるだろうと考えがちですが、言語についていえばPython、Ruby、JavaScriptと言ったように表情豊かで、厳しくしつけようとすると、それらはひどく噛み付きます。その経験は、あなたの環境でしばらくの間作業をする必要のある臨時のユーザにとっても同様だと考えるべきです。言語の数を制限することは、期待と異なる言語のセマンティクスの犠牲になる恐れとは無縁でいたいと考える、内部のあらゆるコードベースに寄与する(例えば20%)全ての者にとって、より楽をさせるための最初のステップです。
企業が"公式に"サポートする各言語は、非常に多くの負担を強いることになります -- インフラストラクチャのサポート、ドキュメント、開発者へのトレーニング、コードの重複、そしてほかの様々なマイナス面です。プログラミング言語は、誰もが知っている標準的な機能と、理解にますます苦しむようなわかりにくいセマンティクスが長い尾のように続いており、特にPerl、Python、Ruby やその同類といった動的言語には実際の仕様はありません。Googleは非常に慎重に、現実的な範囲で言語の数を小さくとどめており、そのため我々が選択した言語のセマンティクス上で専門家の大きなグループを作り上げることが可能になっています。Googleのコードベースがクリーンで、しかも均質になっている理由の一つは、C++、Java、Python、そしてJavaScriptのみを製品化作業における公式な言語として標準化していることです。それはまた、言語の相互運用性によって必要とされるコンポーネントの組み合わせ数が爆発的に増えるのを防いでもいます。
そのため、私はRubyを使うことができません。我々のコードベースの残りの部分との相互運用性のためにも、JVM上である必要もあります。(ここは私の言葉を信じてください -- RPCコールによって解決されることは何もありません; 私はこれをJVM自身の上で動かす必要がありました。)JVM上であるということは、C++や(ネイティブの)Pythonは除外されます。
JVM上で動く言語の選択においては、Steve YeggeはJava、Jython、Rhinoが選択肢だったと述べている。
ハッシュリテラルをパラメータとして使いまわすのが一般的なRailsのAPIを見ると、Javaが特によくマッチするようには見えませんでした。Rubyはメソッドオーバーロードを持たず、RubyとRailsのどちらも可変長引数やブロック(関数)パラメータを渡すといった種類の規約を持っています。そのインピーダンスミスマッチが努力を全て無駄にしてしまうほど、JavaはRubyと異なっていたので、私は動的言語で我慢することを決断しました。
2001年ころからあまり勢いがないということを除けば、当初はJythonを選択するのが自明だと思われました。非JavaのJVM言語の中では恐らくベストだとされていたものです。Jim Huguninは驚くべき仕事をやってのけたのでした。不幸なことに、過去6年間においてあまり愛されてきませんでした。そして今では、Pythonの仕様からメジャーバージョンにおいていくらか後れを取っています(2.2と、もうすぐ2.6)。
Rhino は対照的に、非常に勢いがありました。Jythonよりも歴史は長いです。その生涯はJavaScriptのCエンジンであるSpiderMonkey (Netscape/Mozilla)の移植によってはじまり、パフォーマンスを主眼に置いて書かれています。RhinoのコードベースはだいたいCコードと同様に書かれています。アロケーションを避け、仮想メソッドのルックアップに伴うオーバーヘッドを回避するために可能な限りジャンプテーブルを用いています。それは二つのコードパスを持っています。きついループ内で動くバイトコードインタープリタと、多くの高価なJavaScriptプロパティのルックアップを、Javaのローカル変数やインスタンス変数のルックアップに変更する、Javaバイトコードコンパイラの最適化です。それはソフトウェアの中でもかなり重要な部分です。
そしてJVM言語一般については、
あなたは、言語とそのJVM実装におけるセマンティクスの差を分ける必要もあります。ほとんどの動的言語は特に厳密な仕様を持っておらず、そしてJVMの実装はドキュメント化されていない部分において、Cの実装とはしばしば異なります。私がRhinoの中で本当に好ましいと思うことの一つに、 JavaScriptはちゃんと仕様を持っており(ECMA-232)、RhinoはECMAと異なる部分(例えば、そのマルチスレッドセマンティクスなど)のドキュメントにおいても一流の仕事をしています。そうは言っても、以前としてJavaScriptとJavaのバインディングには考慮すべき点が存在します。Rhinoはかなりよくドキュメント化されているとはいえ、我々のように極端なケースに従事するチームではいくらか時間が取られてしまいますし、型のマッピングやオーバーロードされたメソッド呼び出しなどがどう動くかはしっかり把握しなければなりません。あらゆるJVM言語においては、対応するCの実装が持つよりも、専門家の数がはるかに限られています。こうした観点からは、JVM言語を取り入れることは、そのオリジナルに相当するものを取り入れるよりもより大きなリスクを伴い、ライブラリの相互運用性やJavaがサポートするインフラストラクチャから得ることのできる多くの利益を相殺してしまいます。
Steve Yeggeは彼のブログにおいて更なる情報をリリースしている（source）。それを読んだら、InfoQのこのスレッドに戻ってきてもらいたい。
原文はこちらです：http://www.infoq.com/news/2007/06/yegge-rhino-on-rails
（原文は2007年6月27日にリリースされました）