From: Alder Green Date: 2006-09-02T22:53:59+09:00 Subject: Re: Joel Spolsky on languages for web programming On 9/1/06, Dido Sevilla wrote: > http://www.joelonsoftware.com/items/2006/09/01.html > > Actually, despite the fact that I love Ruby a lot, I'm inclined to > partially agree with him on this. Presently, our company does have > some Rails-based web applications deployed but they're predominantly > applications geared for use by only a few people (internal client use > only); we've not yet tried to deploy a real public-facing web > application based on Rails. For that, it works really well. If anything, your hitherto positive expeirence should cast an optimistic outlook for Rails' performance in a wider-audience application. > high load applications; my own experiences attempting to optimize > plain Ruby code for performance have been simultaneously frustrating > and rewarding. I doubt I could do the same with a Rails app. Rails performacne optimization is very different from Ruby optimization. There's only so much you can to optimize Ruby for simple operations. Web applications, however, are usually complex. Solving or even merely identifying bottlenecks involves making and testing broad changes rapidly. And that's where Ruby/Rails really shines. There are many significant optimizations I was able to discover and implement in Rails, that I simply wouldn't be able to do in PHP because of its less modular and malleable nature. In fact, I think VHLLs like Ruby (in conjuction with appropriate frameworks like Rails) have a solid advantage there over lower level languages, and this edge will only increase in the future. > So for > now we're gonna stick with PHP for our public facing web applications, > even if it is even worse for i18n/l10n/m17n applications than Ruby > is... The first steps I took in Rails were rewriting existing PHP applications with it. So I have a certain estimate about how the Rails compares to PHP for very similar applications. Keep in mind those initial translations were completely naive; I didn't know Rails at the time, and I didn't do anything like the optimizations mentioned above. Generally, those naive applications weren't significantly slower than their PHP equivalents (which themselves were old, tested, optimized code). At most, the PHP was twice as fast (would handle twice the requests over the same time period). And that's a maximum estimate - generally, any difference was hardly noticeable. In my experience a lot of production PHP applications can be optimized to at least 2-3 times of their existing performance (and that's assuming there wasn't really sloppy programming going on, in which case the gain might easily be many times more). So I don't see why Rails is any less viable than PHP in that regard. In fact, quite the contrary: Rails applications I worked on frequently ended up getting some refactoring after going production, and becoming 2-3 times more efficient. Refactoring a working PHP application, however, is commonly such a PITA, I was happy to close the hood after the engine was running and not bother opening it again unless in the unfortunate event of a bug. Regards, -Alder