ゴスリングだって間違える
Java の父と言われる Gosling。業界内では超有名人。
そんな彼でも、間違えることはあるさ。
-- 一部では"JavaはすでにCOBOLのようなレガシーに近い"という声も上がっていますが…。
その意見にはまったく賛同しかねるね。そういうことを一部のRubyユーザなどが言っているのは知っているが、彼らが"RubyがJavaに取って替わる"と主張する根拠は、単にWebアプリケーションを早く作れるからだろう。だが、(出来上がったアプリの)パフォーマンスなどを見ると、とてもJavaに取って替われる言語になるとは思えない。Webプレゼンテーション層しか扱っていないんだから。その最悪の例がTwitterだ。あの性能、UIは悪夢でしかないね。
http://journal.mycom.co.jp/articles/2008/12/03/javasfather/001.html
Gosling の間違いは 2 点。
まず 1 点目だが、アプリケーションの速度には、言語の速度はさほど関係しない*1。もちろんこれはアプリケーションの性質で変わるんだけど、業務アプリや Web アプリの場合には、言語の速度よりも設計やライブラリのような言語以外の要素のほうがよほど影響度が大きい。〔追記: ちょいと修正〕
たとえば動画のエンコーダとかのような CPU bound なアプリだと、ハードウェアに近い言語のほうが有利。しかし Java の利用場面として最も大きな割合を占める業務アプリや Web アプリの場合は、言語そのものの速度よりも、I/O を工夫したり DB や SQL をチューニングしたり memcached を使ったり reverse proxy 使ったりするほうがよっぽど大事。
特に DB のチューニングは超大事。たとえばプログラミング言語を換えたところで、アプリケーションの速さはせいぜい 2 倍速くなるかどうかの違いしかない。しかし DB をチューニングすると、平気で 10 倍ぐらい速くなったりする*2。
フレームワークやライブラリの選択も重要。同じことをするにも、使用するフレームワークライブラリで性能は大きく変わる。たとえば JSF なんて、まさに重たいフレームワークの代表。もしかしたら今はましになったかも知れないけど、昔簡単なベンチマークしてみたときは、Servlet + JSP より 3 倍遅かった。なんであんなに遅いのか詳しくは知らないけど、たぶんわざわざ Bean をシリアライズして HTML に埋め込んでいるのがいちばんの原因じゃないかと思う。つまり、JSF のアーキテクチャのせいで遅いということ。
その JSF はまさに Web プレゼンテーション層の技術だけど、ほかには JSF じゃなくて XSLT を使ったシステムを見たことがある。でも知っている人は知ってると思うけど、XSLT は超遅い。そんなの使ったら、いくら Java で作ろうとパフォーマンスなんてでるわけない。おとなしく Velocity でも使っておけばいいものを、XML バカが XSLT を使ったせいで CGI より遅い Java アプリケーションが出来上がりましたとさ。
あとキャッシュね。アプリを速くしたいなら、Java 使うよりも memcached 使うほうがよっぽど重要。memcached に限らないけどキャッシュを使うと負荷の削減と分散ができるので、アクセス数やデータ量の多いシステムでは、言語がどうのこうのよりもキャッシュをどうするかを考えるべき*3。
よく、Ruby や PHP は遅いから Java を使うという人がいるけど、実際のアプリの中身を覗くと、index つけてなかったり、大量の SQL を発行してたり、キャッシュをまったく利用してなかったりというのばっかり。そんなところは放置しておいて、「速いから Java にする」というやつはほんと素人だと思う。Java を選ぶなら、「JVM が安定しているから」「商用サポートが受けられるから」「型があって保守しやすいから」といったような理由で選ぶべきであり、速さを理由に選ぶのはバカのすることだ*4。
昔、Swing が登場した頃は、遅いし重いしで非難を浴びた。そのため IBM は Eclipse を作る時に SWT という機種依存のライブラリを使った。その後、Swing はチューニングを重ね、いまでは Swing を使った NetBeans は Eclpse より軽いと言われるようになった。これなんか、まさにアプリケーションのパフォーマンスと言語のパフォーマンスは違うということを顕著に表した例である。それなのに、このことを忘れている Java 屋さんのなんと多いことか (Gosling 含む)。
次に 2 点目だけど、こちらで紹介されているように、Twitter が遅い原因は Ruby ではない。
一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにlashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。
ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。
Twitterがスケールに苦しむ理由 - Tous Les Jours 攻防記
詳しくは引用先を読んでもらうとして、外野があれこれ推測したのではなく、Twitter の前チーフアーキテクトが「Twitter が遅いのは Ruby のせいではない」と断言していることは、もっと知られるべきだろう。少なくとも Gosling は知らなかったわけだし*5、ほかにも知らない人はたくさんいると思われる。
ちょっと話はそれるが、Gosling に限らず速度を理由に Ruby や Rails を叩きたい人は相当数いるようだ。このまえ yodobashi.com で障害が発生した時も、Ruby のメーリングリストにこんなのが投稿された。
Subject: [ruby-list:45600] Railsのヨドバシカメラのサイトが「動かないコンピューター」状態？
From: yodobashitimeout mail.goo.ne.jp
Date: Wed, 29 Oct 2008 23:54:23 +0900
こんにちは。下記、Ruby on Rails が使われていると一部で噂になってますが本当でしょうか？？
［ruby-list:45600］Railsのヨドバシカメラのサイトが「動かないコンピューター」状態？
しかし実際には、yodobashi.com は Ruby ではなく Java で構築されたシステムであった。まさに、アプリケーションの速度に言語はさほど関係しないことを、悪い意味で証明したことになる。
そしてここで大事なのは、わざわざ捨てアド取ってまでこういうことをするような人が、世の中には存在するってこと。投稿者が「yodobashi.com は Ruby on Rails を使っている」という間違った情報をどこで入手したかは知らないが、それをわざわざ Ruby の ML に投稿してくれるのだから、明らかに悪意を持っている。しかし実際には Ruby ではなく Java であったため、結果としては逆に Java での失敗を宣伝することになってしまった。御愁傷さま。
:
:
話をもとに戻そう。なんにせよ、Gosling の認識は間違っている。この程度の間違いで彼の今までの功績に傷がつくことはまるでないけれど、Gosling ほどの大物でも間違っていたのだから、他にも大勢の人が間違っているだろう。
また「アプリケーションの速度 != 言語の速度」ということは、逆にいえば「Ruby や PHP だから遅い」という言い訳が通用しないということでもあり、また Ruby 1.9 になれば Rails アプリが速くなるというのは幻想だということでもある。Ruby に限らず LL を使ったアプリが遅い場合、それは言語のせいではなくプログラマーのせいである。
・・・自分にとっては結構厳しい結論だな。
