Rubyを飲み込んでしまうJava ― ＠IT

Javaプラットフォームの包容力 先週、記者はJavaOne取材でサンフランシスコにいたため、個人的に気になったのは、Java関連のニュースだ。 中でも印象に残ったのは、Java VM上に実装したRubyの処理系「JRuby」の開発者が、JRubyのほうがCで書かれた本家のRubyよりも動作が速いと話したことだ。 “Java”といったとき、一般的には言語としてのJavaを指すが、サン・マイクロシステムズ自身はJavaテクノロジー、Javaソフトウェア、Javaツールなどの名称を使い分けている。言語としてのJavaは、Javaテクノロジー全体のもっとも重要なピースの1つではあるが、一部分に過ぎない。JRubyやJythonといったほかの言語の処理系がJava VM上で高速に動くとなると、“Java”を使うことのメリットはJavaという言語が持つ良さにとどまらず、Java VMのパフォーマンス

[webmarksjp]

Java

[jimmyhomma]

バックにサンというブランドを得て、性能や普遍性で勝るJRubyが、Rubyワールドのヘゲモニーをいつの間にか奪ってしまう可能性も否定できない。

[mappochi]

JRuby

[diary193]

Ruby文法さえ統一されるんならRubyがRubiesにフォークしても気にしない

[FTTH]

地味だが。

[hiro_y]

JVMの優位性とRubyの今後。

[Trapezoid]

nativeなRubyはYARVでもスレッドは対応してるもののマルチコア非対応らしいからなあ。

[ttpooh]

JRubyはnative Rubyより速いらしい、言語処理系 on JVMはマルチコア対応で有利、など。

[kit-call]

rubyは気になる。javaは仕事で使ってる。

[yojik]

この件に関しては、まさに杞憂だと思う

[tks_period]

VM自体の性能とか調べてみたいな。

[fromdusktildawn]

本格的なマルチコア時代が来ると、ますますCで書くよりチューニングされまくったVM上で言語処理系を実装した方が高速になると思われ。VMのチューニングされたGC、スレッド、ライブラリをそのまま拝借できるし

[myrmecoleon]

Rubies

[adamrocker]

Rubyの処理系をCで書くのよりJavaVM上で実装したほうが高速という話は興味深い。おそらくJITをかけ易いといったような動的最適化が利きやすいのだろうRubyは。クロージャなどは変数の使用範囲が明示的だからかな？

[another]

否。むしろ処理系が複数個ある方がたぶん健全。

[saoshima]

Ruby JRuby Linux Linuxの開発体制が民主的だって？(w

[kakutani]

どうなっていくんだろうね

[cinnabar]

1.0はいつ？

[yugui]

Rubyコミュニティのガバナンスに関する指摘

[foursue]

今時Javaが遅いというような意見を聞くとは思わなかった。