思いっきり個人的な見解です。無知であるが故の部分も大きいと思います。
「そんなことねーぞ、こういうのもあるぞ」
っていうのがあると、教えて欲しかったりしてます。
正直、国内でのRuby人気は気になるのです。Rubyというか、RubyonRailsですよね。
2年位前は「Rubyすげえ！Railsすげえ！」だったんです。その前はPHPばっかり書いてました。
でも、RoR使うようになってフルスタックのフレームワークの便利さに魅了され、RoR一本でいくつもりでした。
まぁPHPの前はC#（ASP.NET）ばっかり書いてた頃もあったのですが。ちなみにその前はaspでした。
そんななか、Googleが導入し、GAEでも使えるPythonにも興味がありました。もともといろんな言語を使えるようになりたいとも思っていたので、新規プロジェクトの際にちと手を出してみたんですね。Python+Djangoに。
当時、Apacheにpassengerを組み合わせてRoRを走らせていたハセテツには一定時間ごとにインスタンスが終了されてしまうのが「なんだかなー」でした。アクセス数の多いサイトであれば気にならないのでしょうが、少ないサイトのだったのでリクエスト時に多少のタイムラグがあることが気になってしまっていました。
Python+Django、mod_wsgiはそれを解決してくれました。まぁmongrelでもよかったのかもしれませんが、当時は開発が止まっていた時期だったと。今はthinとかもあるから問題ないのかもしれませんね。
CakePHPやsymfonyは選択肢に入りませんでした。ステップ数が多くてリクエストごとのレスポンスが遅すぎました。APCとか使えばそれなりらしいのですが、そもそもPHPは手軽に書けるのが魅力だと思っていたので、フレームワークのお作法に従うのは違うなーと。
実際、Pythonがよかったのではなく、Djangoがよかったのかもしれません。それくらいDjangoはよくできていました。RoRのfind_by_sqlに匹敵するものがないのは残念ですが。
Djangoだとurlディスパッチャーは自分で設定というか、urlとコントローラを紐付けてやらないといけません。Railsのようにcontrollerが自動的にurlと紐付かれたりはしません。が、それが自由自在で便利でした。
フレームワークを経由しないでApacheから直接レスポンスを返す静的コンテンツを置くディレクトリの指定も簡単です。フレームワークから「ここに置け」って指定されることもありません。
Railsはループ処理のときは一件ごとにsqlを発行しましたが、結合して一気に取ってきてくれます。ちゃんとO/Rマッパーが外部結合してくれます。
Djangoも、syncdbした後にmodelの設計を変えると面倒くさいという不満はあります。まぁそれは事前にきちんと設計しておけばいいだけの話なのですが。
モジュールの多さという点では、PythonもRubyもPHPも必要なものはそろっているという印象です。「RubyにはあるけどPythonにはない」っていうのはなかったかと。
あ、PHP版のMeCabバインディングはなかったか。
あ、あとRoRってひとつのプロジェクトで複数のWebアプリって作れませんよね。
実際こうやって書き出してみると、たいした理由じゃないですね。ちっさな「うーん、なんだかなー」の積み重ねだったりしてますね。
でも、そういう小さな積み重ねって技術者にとっては大事だったりすると思います。不満だった点も、当時はそうだっただけで今はとっくに改善されているのかもしれません。
結局、Python書けるようになってもGAEのアプリは一本も書いてません。それでも、Python+Djangoを選択してよかったと思っています。
うまい感じにオチをつけられないのですが、いろいろ試した結果、もうしばらくはPython+Djangoでいってみようと思います。
メインの言語を持った上で、いろいろな言語、環境のプロジェクトがこなせるように勉強だけは欠かさずにしないといけませんね。
技術者は死ぬまで追いかけ続けるんだろうな。下りのエスカレーターを上っていくように。
立ち止まったらどんどん落ちていくんでしょうね。