GroovyまたはJRuby

2007年11月28日

ruby

現在、Java仮想マシン上で動作するスクリプト言語として、GroovyとJRubyのどちらが優れているかについて、かなり激しい議論が繰り広げられています。好奇心旺盛な人々は、この間近に迫った言語戦争でどちらの言語が勝利するのかを知りたいと思っています。プロジェクトにどの言語を選ぶべきか、あるいはどの言語を学ぶことにコミットすべきかを知りたいのです。

おそらく最初に指摘すべきは、この競争を特定の2頭の馬の競争と見なすのは、やや不公平かもしれないということです。スクリプトはJVM上で長い間利用可能でした。PythonのJava実装であるJythonは、数年前から存在しています。他にも、私が言及を避けると、漏れてしまったすべての言語を怒らせてしまうかもしれない、もっとマイナーな言語がたくさんあります。

JRubyは、Ruby言語全般への注目、特にRailsに関する関心によって火がついた注目を集めています。Thoughtworksでは、RubyとRailsの仕事に対する関心が急増しており、JRubyは既存のJavaインフラストラクチャを使用してRailsアプリケーションをデプロイできるため、さらなる次元を追加しています。

Groovyは、他のどの言語よりもJVMとシームレスに連携するように設計されており、初期のJSRから多くの注目を集めています。

個人的には、開発が停滞しているように見えた数年前にGroovyへの関心を失っていました。しかし、1.0リリースと、同僚からのさらなる興味深い肯定的な意見により、再び注目し始めています。

まずは類似点について話しましょう。JRubyとGroovy（そして事実上Jythonも）は、どちらもモダンなOOスクリプト言語です。スクリプト言語の厳選された簡潔さと、より大きなプログラムを構築するための優れた堅牢な構造を兼ね備えています。そのため、古典的なスクリプト作成とより大きなプログラムの記述の両方に適しています。どちらも動的型チェックに慣れていますが、Groovyは静的な機能もいくつか提供しています。どちらも、この種の言語で人々が求める表現力の向上に重要な機能であるラムダ式をサポートしています。

それらの最大の相違点は、より広範なプラットフォーム哲学です。Groovyは、Java用のスクリプト言語として設計されています。可能な限り、構文はJavaの同等の構文と一致するように試みられています。（switch文のデフォルトのフォールスルーのような醜いものも含まれています。）また、Javaのクラスライブラリとも直接連携しますが、クロージャのようなものを使用するために不可欠な、多くのメソッドをJavaのクラスに動的に追加します。

しかし、JRubyはRubyプラットフォームのJava実装です。Rubyは、Cランタイムで主流のオペレーティングシステム上で直接実行でき、.NETのCLR上でも実行され始めています。JRubyでプログラミングするときは、主にJavaで実装されたRubyのライブラリを使用し、必要に応じてJavaのライブラリも使用できます。Rubyのライブラリを使用するか、少なくとも外部要素をラップする場合は、C、Java、または（いずれ） .NETランタイムでRubyプログラムを実行できます。したがって、JRubyを使用すると、JVM上でRubyプログラムを実行するだけでなく、JVMをスクリプト化するための言語としても使用できます。

JRubyとJythonの大きな違いの1つは、ライブラリに関するものです。この種のスクリプト言語をJVMに移植する際の難しい側面の1つは、これらの言語が通常、Cで実装されたライブラリと密接に絡み合っていることです。これらのライブラリをJavaに移植するには、ライブラリをJavaで書き換える必要があります。Jythonはこれをあまり行わなかったため、多くのPythonアプリはJythonで実行できません。しかし、JRubyの実装者は、Railsアプリを実行することを目標に早期から決定したため、すべてのRuby標準ライブラリを含む多くのライブラリを移植する必要がありました。

JRubyがJVM上のRubyプラットフォームであるという事実は、JRubyにはJRubyオブジェクトとJavaオブジェクトの2種類のオブジェクトがあることを意味します。2つが相互にやり取りし、変換する方法はありますが、違いはあります。Java文字列を扱っているのか、JRuby文字列を扱っているのかを知る必要がある場合があります。Groovyにはその境界はなく、Javaオブジェクトのみが存在します。

どちらの言語が勝つかを言うのは時期尚早であり、むしろ困難です。どちらもかなり若く、JVM上でようやく足場を固めているところです。より個人的なレベルでは、あなたの選択は、それを使って何をしたいかによって大きく左右されます。JVM上での実行のみに関心がある場合は、Groovyがより簡単な選択肢となる可能性があります。Javaのライブラリとオブジェクトモデルを直接操作しており、構文に慣れる必要も少なくなります。Rubyを好む強力な理由は、複数の実装に存在するという事実です。Rubyは他の多くの場所で使用できるツールです。長年のRubyistとして、個人的にはGroovyに深く関わるインセンティブはあまりありません。実際、見た目からすると、私はこの言語をかなり気に入っていますが。

Railsは重要な要素です。Javaの世界では、Webフレームワークが不足しているわけではありませんが、Railsは使用した人々に広く好まれています。Grails（Groovyの模倣品）についてはまだ多くの報告がないため、断定的な意見を述べることはできません。しかし、RailsでWebアプリをデプロイできる機能は、JRubyを人気にする大きな要因になる可能性があります。もう1つ注目すべきは、テスト環境の新しいスピンであるRSpecの成長です。

プラットフォームにおいては、技術的な要素だけでなく、コミュニティに関与する人々も同様に重要です。優れた人々は技術的な弱点をすぐに克服でき、活気のあるコミュニティは大きなイノベーションの強力な源泉です。Rubyの人々は特に強力なコミュニティを形成しており、すでにRails、Rake、Rspecなどのものが生まれています。

どちらかがJavaにとって重要になるでしょうか？結局のところ、JythonはJVMに大きな影響を与えることなく長い間存在しています。ツールサポートは、現在のJavaのツールサポートと比較すると、これらの言語のいずれにとっても率直に言ってひどいものです。

Javaは実際には転換期に差し掛かっていると思います。つい最近まで、Javaの叫びは1つのVMと1つの言語でした。（C#またはVBを提供している限り、1つのVMと多くの言語の叫びで始まったCLRとは対照的です。）人々がJavaの限界を認識し、さまざまな機能を求め始めるにつれて、これは変化しているようです。将来は、複数の言語がJVM内に密接に統合される可能性があります。

RailsとRubyに関する誇大宣伝を嫌う人はたくさんいます。しかし、Rubyが嫌いな場合でも、この誇大宣伝は新しい言語への関心の復活につながりました。この誇大宣伝がなければ、Groovyへの関心が今ほど大きくなるとは思えませんし、Jythonが眠りから覚めることもなかったでしょう。ruby/railsの誇大宣伝は、他のエキゾチックなJVM言語への関心も生み出しました。ここで本当に素晴らしいのは、JRubyの人々が、ここでのポイントは多言語の相互運用性とイノベーションを促進することであると認識して、動的なライバルを奨励していることです。