「Ruby なんて遅くて使えないよねって言ってみる」を読んで：
逆でしょう。RubyやRailsは遅いから使えるんです。
論点を整えますが、設計者、主にプログラマから見て「使える」と表現しています。
経営やプロジェクトマネジメントの観点まで広げると、Railsを採用するということは端的に言えば、「開発フェーズを効率化して運用フェーズでコストとして被る」ということです。
ビジネスプランも加味した上でのトレードオフになります。
言語のパフォーマンスを重視してみたところで無駄 - 開発者はみんなフレームワークを欲しがる：
文句無しにパフォーマンスが良いので、Cで全てを書くとどうなるかです。設計の初期段階で似たような処理が存在することを想定できたり、開発したりしているうちに、やはりフレームワークが欲しくなってくる。
狭い開発グループでしか使わないようなフレームワークなので、もはやこれは野良フレームワークですね。
多分に独自な設計で作られ、テストケースは通したから想定する範囲では普通に動く。
リリース後の荒波に揉まれていないので、バグやらセキュリティの問題も潜在的にはいっぱい含まれている何とも野良なフレームワーク。
でもそいつはある程度の形になって完成する。
企業規模によっては野良フレームワークを開発プロセス組み込み、自社方法論と銘打てるまで昇華させたりもします。
残念なことに野良フレームワークの誕生で、パフォーマンスが低下していく：
僕が2000年辺りに作って今でも細々と運営している「ぴのこ村」の９割はCで書かれています。当時は実験的な意味合いから作っていたのですが、それでもやっているうちに野良フレームワークが出来上がっていきました。
正確な数字は計測していませんが、新規に開発する分量を減らすためにフレームワークが大部分の処理を賄うようになっていきます。
汎用性を切り捨ててモリモリ実装したコードの実行時間と比較すると、10倍程度遅くなるのは仕方ないでしょう。
僕は常に思うんですが、Rubyのようなスクリプト言語は、Cで作られた新しいフレームワークと同一ではないかと。
コーディングとは突き詰めていけば新たに言語を設計するようなものですし。
Ruby on Railsは「Cで作られたフレームワーク(=Ruby)」をベースとした「Webのためのフレームワーク(=Rails)」です。
天才が作ったこともあり当初から輝いてはいましたが、万人に晒されて更に磨かれ、Twitterのような実績も生まれました。
どう考えても自分で作ったCの野良フレームワークと比較するとRailsの方が遥かに優秀です。
野良フレームワークを作っている時間や費用の方がもったいない。
仮にあなたは設計者でありプログラマで、万物を生み出せる無二の天才的頭脳の持ち主だとしましょう。
もし、そこがCしか無い世界であれば、天才のあなたはパフォーマンスと引き換えに結局Ruby on Railsを作ることになります。
本当にパフォーマンスを得たいのであれば、フレームワークなんか使わない・作らないこと：
Rubyを採用することで失ったパフォーマンスはスケーラビリティのコストとして後々表面化します。またスケールアウト時にはマシン台数が増えて、メンテナンスのランニング費用が特に脹らむことでしょう。
これが先に表現した「開発フェーズを効率化して運用フェーズでコストとして被る」話になります。
結局Cを採用しても野良フレームワークを作ってしまうとパフォーマンスの低下が起こるわけで、あとは所詮程度の問題です。
あるプロジェクトは満足するかも知れないし、しないかも知れない。
これはここで議論しても仕方ないので、本当にパフォーマンスを得たいのであれば、野良を含めあらゆるフレームワークは諦めるしかないんじゃないかと思うわけです。
そのURLへのリクエストのためにどう処理するかを丹念に作っていけばパフォーマンスは劇的に向上しますよ。
すると今度は逆のことが起こります。
「開発フェーズにコストをかけた分、運用フェーズのコスト削減ができるかも知れない」と。
昨今のビジネスプランの風潮は「さっさとリリース」：
- 開発フェーズに時間をかけてしまうと、その間に同じサービスが出てきてしまいます。
- 数多く色々なサービスを短期にリリースして試してみる方が重要です。
- 長く運用しなければならないような大ヒットサービスが出てくるのは稀です。
しかし、日本のエンタープライズ分野の殆どがこれとは真逆。
- プロジェクト全体の期間は決まっているけど、開発フェーズに限って急ぐ必要は特にありません。
- 一品物をしっかり動く状態でリリースするのが重要です。
- 長く運用できるほうが嬉しい。業務上どうしても使わなければならない必要悪なサービスすらあります。
それでも今後は三角合併だとかM&Aが増えたり、SOAなどの観点が入ってきてエンタープライズ分野も少しずつアプリケーションのあり方が変わってきていますから、さっさとリリースすることが重要なケースも増えてくるのではないでしょうか。
遅ればせながら、その時Ruby on Railsを採用する意味が出てくるのではないか、と思います。
補足：
まつもとゆきひろさんの日記にもありますが、YARVが今後パフォーマンスを改善していくだろうとのこと。失うパフォーマンスを最小にするという改善活動には頭が下がります…。
もう野良フレームワークを作る意味は全く無い。もう全部Rubyでいいじゃないか！
逆に、サーバを運用するインフラエンジニアからすると
無駄にリソース食いまくるハイエナやハゲタカみたいなアプリは
さっさと切り捨ててほしいわけです。
金を産む卵なら話は別ですが。
まぁ、１ヶ月で作って半年で廃棄するシステムを作っては壊し作っては壊しを繰り返しても
大して金にはならないでしょう。
しかもその間サーバやネットワークはずっと有り続けるわけで。
仮にサービスがヒットしたならヒットしたで
それなりに長く使われます。
その時は、運用コストが利益率を決めますね。
ヒットしたサービスはなかなか思い切った改修ができないので
後のことを考えずにササッと作ったものを継ぎ接ぎで騙し騙し運用していくと
後々ものすごく大きな運用コストを払うことになります。
リプレース費用とか、デスマーチとか、大量の手運用とか、数々の障害対応とか…短期開発でもいいですが、少なくとも運用を考えずに開発するのｄけは、オススメできません。