I couldn't disagree more. Having tried both platforms, I felt like I was coding with one hand tied behind my back when I was learning Python, Pylons and Django. Web tools and the stack is a lot less mature than RoR stack and the amount of various plugins/gems available for both platforms was not even close. RoR plugins were so much more mature and multitudinous that after we started planning our app, we realized that we'd have to spend about 6 months(!!!) just writing the functionality in Django/Pylons that we were getting for free with Rails. Now this was about one year ago so things might have changed.
Since I don't have the time to go over each point that the author makes, I'll concentrate on a couple.
Lack of Unicode in Ruby 1.8.x. OK, so this might have been an issue before RoR 1.2 came out but since 1.2, RoR has introduced Multibyte and has been a lifesaver. Now, I don't have a clue how many Rails Unicode apps the author has written in his career but I can tell you for a fact that Unicode is not an issue in Rails anymore. We have an app in beta that uses Unicode for every string that we handle and we handle so many strings for so many languages that your head will spin. We haven't had any huge issues with RoR's Unicode support at all. So that argument is really a moot point.
As for language performance, who really cares?! Programmer's time is so much more expensive than servers so the last thing I worry these days is how fast some specialized benchmark runs. As long as the latency is acceptable and you can solve the problem by parallelizing it, the performance of an interpreter is completely irrelevant.
I think his point about performance was more that the rails developers were not taking significant steps to improve it. From what I understand, they are doing this for Ruby 2.0.
He definitely addresses the programmer time thing a lot, except from the perspective of code readability instead of keystrokes or whatever other metric you might use. Python is generally a much more readable language, and might make for more maintainable large scale systems because of it.
>From what I understand, they are doing this for Ruby 2.0.
In less than a year's time, you'll have so many choices to choose from. Ruby 1.9 is just one of the Ruby interpreters that you'll be able to pick from. There's also Rubinius (which is already outperforming MRI on so many benchmarks)
And you'll also be able to choose from JRuby and IronRuby. The way I see it, I think there's more work being done on improving Ruby's than Python's ecosystem.
Ruby people should be more candid about the performance situation, which is a catastraphuck. It is worth it, it will probably get better, and raw performance isn't that important for I/O bound apps, but Ruby is noticeably slower than pretty much all its competitors.
People make this claim all the time but I never hear anyone talk about actual examples where they were bitten by this.
People especially like to harp on the speed of ruby as a knock on ruby on rails. However I have not once run into a real life situation where the performance problem was directly related to the raw performance of Ruby. I have though run into plenty of performance problems:
* At Odeo (RoR circa 2005) we had plenty of problems with memory leaks in our FCGI (this was 2005!) processes and in feed_tools (well known to be slow)
* At my next company we quickly ran into situations where pages were slow to load due to the sheer number of database calls. When I started doing web apps I can remember never having more than three queries behind any given page. Some of our pages were doing 500 queries. This was easily fixed but Rails definitely tempts you to put up scaffolding which you then have to rework once it starts getting real use. In my experience this is a good thing. I'm twice as likely to throw away the scaffolding than I am to have to rewrite it.
* Twitter, which is the poster child for RoR scaling issues, actually actually has had almost all their problems on the backend, having to rapidly change their database and message queue architectures and deal with flaky service providers (AOL and phone companies). Again nothing to do with the architecture they launched with.
So, in the lab Ruby is a slow language, but in the real world how is this biting people?
Like I said earlier, our app parses with racc, does cryptography, and a fair bit of analysis. It is not heavily database dependent. Most of our I/O is memcached. I assert without evidence that Ruby's performance deficits have in fact bit us.
Comments
I couldn't disagree more. Having tried both platforms, I felt like I was coding with one hand tied behind my back when I was learning Python, Pylons and Django. Web tools and the stack is a lot less mature than RoR stack and the amount of various plugins/gems available for both platforms was not even close. RoR plugins were so much more mature and multitudinous that after we started planning our app, we realized that we'd have to spend about 6 months(!!!) just writing the functionality in Django/Pylons that we were getting for free with Rails. Now this was about one year ago so things might have changed.
Since I don't have the time to go over each point that the author makes, I'll concentrate on a couple.
Lack of Unicode in Ruby 1.8.x. OK, so this might have been an issue before RoR 1.2 came out but since 1.2, RoR has introduced Multibyte and has been a lifesaver. Now, I don't have a clue how many Rails Unicode apps the author has written in his career but I can tell you for a fact that Unicode is not an issue in Rails anymore. We have an app in beta that uses Unicode for every string that we handle and we handle so many strings for so many languages that your head will spin. We haven't had any huge issues with RoR's Unicode support at all. So that argument is really a moot point.
As for language performance, who really cares?! Programmer's time is so much more expensive than servers so the last thing I worry these days is how fast some specialized benchmark runs. As long as the latency is acceptable and you can solve the problem by parallelizing it, the performance of an interpreter is completely irrelevant.
I think his point about performance was more that the rails developers were not taking significant steps to improve it. From what I understand, they are doing this for Ruby 2.0.
He definitely addresses the programmer time thing a lot, except from the perspective of code readability instead of keystrokes or whatever other metric you might use. Python is generally a much more readable language, and might make for more maintainable large scale systems because of it.
>From what I understand, they are doing this for Ruby 2.0.
In less than a year's time, you'll have so many choices to choose from. Ruby 1.9 is just one of the Ruby interpreters that you'll be able to pick from. There's also Rubinius (which is already outperforming MRI on so many benchmarks)
Take a look here: http://programblings.com/2008/04/01/rubinius-for-the-layman-...
And you'll also be able to choose from JRuby and IronRuby. The way I see it, I think there's more work being done on improving Ruby's than Python's ecosystem.
"In less than a year's time" is not in conflict with "isn't ready".
Also, Python already has jython and IronPython, and there are numerous other projects in the works, notably including PyPy and Pyrex/Cython.
Ruby people should be more candid about the performance situation, which is a catastraphuck. It is worth it, it will probably get better, and raw performance isn't that important for I/O bound apps, but Ruby is noticeably slower than pretty much all its competitors.
People make this claim all the time but I never hear anyone talk about actual examples where they were bitten by this.
People especially like to harp on the speed of ruby as a knock on ruby on rails. However I have not once run into a real life situation where the performance problem was directly related to the raw performance of Ruby. I have though run into plenty of performance problems:
* At Odeo (RoR circa 2005) we had plenty of problems with memory leaks in our FCGI (this was 2005!) processes and in feed_tools (well known to be slow)
* At my next company we quickly ran into situations where pages were slow to load due to the sheer number of database calls. When I started doing web apps I can remember never having more than three queries behind any given page. Some of our pages were doing 500 queries. This was easily fixed but Rails definitely tempts you to put up scaffolding which you then have to rework once it starts getting real use. In my experience this is a good thing. I'm twice as likely to throw away the scaffolding than I am to have to rewrite it.
* Twitter, which is the poster child for RoR scaling issues, actually actually has had almost all their problems on the backend, having to rapidly change their database and message queue architectures and deal with flaky service providers (AOL and phone companies). Again nothing to do with the architecture they launched with.
So, in the lab Ruby is a slow language, but in the real world how is this biting people?
Like I said earlier, our app parses with racc, does cryptography, and a fair bit of analysis. It is not heavily database dependent. Most of our I/O is memcached. I assert without evidence that Ruby's performance deficits have in fact bit us.