我怎么就觉得rails适合做大型应用

1. REST
SOA可以在网上搜得到大量文章，就REST这个通信部份，我就说一下：
通常的项目中用不到，但当项目较大时，会遇到.Net和java的通信，老版本j2ee平台和新架构（比方spring，只是比方）的通信，这里老的项目支持某一种或两种协议，这时，你要调取别人的服务就得用别人能懂的协议，虽然，REST不错，但你这里无法对老的系统全改为REST，代价大，风险大。也许你会说，针对每种协议写一个Adapt就可以啊。是的，是一种方法。SOA（有很多轻量级open source的SOA，不一定非要用钱去买）对你说，你不用写了，我帮你写好了。

2. 太多太多的东西
一是指各种component，像我们平时用的各种apache library，各种j2ee中提及到的服务（像tx, mail, jms等等）。rails在这一部份很缺少，虽然他的component在不断增长，但相比java，太少。
二是指解决方案，方案这东西，不能保证你快，但他能保证你的安全，性能。上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应。rails在这一部份很缺少，你得在定方案前做各种检验。
三是指兼容性与集成性，全新的东西是好办事，但你不能让企业把它运行得好好的东西全部重新开发吧。那么怎么集成，如何平滑的升级，这里又是一堆要做的东西。rails在这一部份也没怎么见过。

3. 轮子
关从技术角度，.Net还真是这样。但从商业角度，从兼容性等方面来看，那就不是了。

4. 开发速度
的确，j2ee的方式是慢，看上去java比不上rails，但是，这个问题要看架构师如何设计你的架构，如何利用或改装现有组件。思想是相通的，rails代表的是思想，而这种思想在java上实现是一样可以做到的。

5. 欧美项目
我知道瑞士银行的一个核心项目也在用SSH（非门户之类，涉及到具体投资、资金方面），这句话好像有点抬杠，我主要是说，在面对新兴的技术，其实是有各种选择。rails最大的问题是优势不明显（从架构的角度），底气（component,项目证明等）又不足，所以现在不是它用于做大型应用的时候。