谈谈Grails，以及Ruby on rails

刚跑到grails的Issue去看了一下。妈呀，吓死人啦。
这东西压根就没法用

如果一个J2EE服务器只用单线程处理所有的业务，那不几乎就是单进程模式了，我们无需讨论任何东西了

关键问题在于J2EE充分利用了线程处理相对独立，编程模型比较简单的优点，让每个用户请求都在自己的线程里面处理自己的事情，而不需要考虑别的请求。这是一个巨大的优势

而我们也是基于这一点进行讨论的，当一个系统中线程数目达到一定程度的时候，操作系统可能加以限制，或者系统可能产生颠簸着个问题。网络只不过是一点而已。


至于Ruby语言和Java语言的比较，有一些是语法上的，而某些则是虚拟机级别的。

Ruby的Vm有很多巧妙的设计。譬如Java和Python的字符串都市不可修改的，必须用StringBuffer之类，而Ruby则可以修改，并且效率极高，占用内存极低（共享），不会产生大量的小对象垃圾，减低垃圾收集的频度和内存碎片的产生。这是属于VM级别的问题，只不过Ruby1.0的Vm不支持native thread和byte code，所以没有体现出优势来。

在语法上,Ruby的代码就更加可读，更加人性化。表达力更强，对于普通的Java程序，我可以至少把代码缩减到1/2-1/3,并且非常容易阅读。Ruby的目标就是无惊异编程，为了程序员编程程序和阅读程序的方便，在语法解析和虚拟机级别作了大量的工作。


代码行少了，可读了，维护量少了，修改量少了，增加新功能的时间也减少了。Bill gate不是说了，以后软件唯一的度量标准就是代码行的多少，虽然有点夸张，但是却说出了绝大部分的事实。

用Ruby写程序让我重新体味到了95年第一次接触Delphi编写Window界面的感觉，在这之前我深陷在C++编写上百行代码才能出现一个窗口的泥潭中。

就我自己来讲，除了工作需要之外，如果可以选择，我相信很少再会用Java去编写程序了。C当然是一直要写下去的，也是我目前这个公司一半产品的开发工具。另一半目前是在J2EE上作的，但已经在用Rails实现一个新的版本。这也将是我们公司产品WEB层次的主要方向。


我们的产品或许有可能会在很多地方成为电信级别的运行平台，内容将涉及到运营、计费、GPS/WebGIS系统、设备的维护、监控、网络管理、无线服务等等，很多我基本上都能找到对应的开源项目，只不过Quarz确实没有、Lucene还没有完全开发成熟、规则引擎也没有看到。通过Ruby和C的结合，我相信最终能够在开发效率、维护、可扩展上超越J2EE和C的结合。

你是不是应该下载grails发行包，然后自己编写简单的程序跑一下再来下这种吓死人的结论呢？

不过我们最近在做很多服务器的编程（不是Ｗｅｂ方面的），最后发现要达到大量的用户并发和充分利用网络的带宽，多线程必须被抛弃。进程的线程数限制和系统用于线程切换的时间已经大大浪费了网络的处理能力和系统的资源利用

4. Serve one client with each server thread

... and let read() and write() block. Has the disadvantage of using a whole stack frame for each client, which costs memory. Many OS's also have trouble handling more than a few hundred threads. If each thread gets a 2MB stack (not an uncommon default value), you run out of *virtual memory* at (2^30 / 2^21) = 512 threads on a 32 bit machine with 1GB user-accessible VM (like, say, Linux as normally shipped on x86). You can work around this by giving each thread a smaller stack, but since most thread libraries don't allow growing thread stacks once created, doing this means designing your program to minimize stack use. You can also work around this by moving to a 64 bit processor.

The thread support in Linux, FreeBSD, and Solaris is improving, and 64 bit processors are just around the corner even for mainstream users. Perhaps in the not-too-distant future, those who prefer using one thread per client will be able to use that paradigm even for 10000 clients. Nevertheless, at the current time, if you actually want to support that many clients, you're probably better off using some other paradigm.

For an unabashedly pro-thread viewpoint, see Why Events Are A Bad Idea (for High-concurrency Servers) by von Behren, Condit, and Brewer, UCB, presented at HotOS IX. Anyone from the anti-thread camp care to point out a paper that rebuts this one? :-)

谢谢！

我讲的这些都是目前我们Java版产品使用的东东。

不过就算ruby for JVM和CLR搞的再好，我也不太会去用的，前面已经说过理由了，我并不相信其理论的可行性，或者说能够充分实现Ruby的特性，或者他的效率能够超过Native C写的Ruby VM。

我并不认为Ruby是一种快速原型语言，而是一种易于阅读、维护、扩展的语言。而快速原型的正确用法是原型然后丢弃。Ruby+c和Ruby+Java并没有什么可比性，只有Ruby+c和Java+C才有可比性。我不可能用Java去写报警处理和分发中心、流媒体服务器、海量视频数据集中存储等服务的。为了性能去Ruby+Java，我看这样的需求基本上不可能，意义也并不是很大。

用规则引擎的唯一用途就是它的Rete引擎，不然就是引入不必要的复杂性，不过我很期待Ruby的DSL能力和Rete引擎的结合在使用的方便性上超过Drools。