BloomBurst: Growing Software with Pop
BloomBurst is written by Matthew Reinbold. He currently lives in Salt Lake, Utah and has been a web designer, site developer, and usability engineer since 1999.
Joel Spolsky is a respected technology guru. He’s a skilled communicator, recommended read for any developer, and the subject of more than one BloomBurst post. And with a recent post criticizing Ruby, he is now the target of a growing web lynching.
Joel didn’t say anything seemingly controversial; he simply pointed out what several application comparison tests have shown: Ruby, for all its hype, is slow. We’re not talking photo finish like speeds here – the difference can be anywhere between ten to fifty (!) times slower. He is like many pundits coming forth right now. The September 1st issue of the Software Development Times sics two of its regular columnists, including Andrew Binstock, on it. Andrew likes the intuitive design but concludes:
“…don’t expect a panacea in Ruby, but a language with its own strengths and weaknesses and an acute need for better tools and better performance.”
Ruby is a new relatively new language and, like most languages, needs some time to mature. The speed increases will come. However, instead of accepting that inevitability the Ruby community got out the torches and pitchforks.
David Heinemeier Hansson, the Ruby on Rails poster boy, was quick to write:
“Rails is for the vast majority of web applications Fast Enough. We got sites doing millions of dynamic page views per day. If you end up being with the Yahoo or Amazon front page, it's unlikely that an off-the-shelve framework in ANY language will do you much good. You'll probably have to roll your own. But sure, I'd like free CPU cycles too. I just happen to care much more about free developer cycles and am willing to trade the former for the latter.”
As Joel is correct in pointing out he has no problem with the framework – it’s Ruby that is questionable. I also agree with Joel’s assertion:
“I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that's just a bumper-sticker slogan and not fair to the people who are complaining about performance.”
Quieting factual evidence by saying something is ‘fast enough’ is like telling everyone that a Kia is a ‘good enough’ car. For some people a Kia fills their needs, budget, and style. But is it for everybody? Even a majority? Absolutely not. Ruby has a niche to fill but it is not the second coming of C++.
Ruby has risen to the level that it has because of a fanatical set of bloggers. It is time to separate the fact from fiction and evaluate the language for what it is, not what the sound bytes say.
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Joel's not just saying that Ruby is slow compared to other languages. He makes the claim that it will have scalability problems. But then he launches into a discussion of how fast Ruby can call a method. However in this, he's not specifically referring to Ruby, he's talking about dynamic languages in general, yet his own product is written in a dynamic language.
Unless that is ridiculously slow, has the speed of a method call been a primary factor in scalability in your experience?
As for separating fact from fiction, Ruby was released in 1995, around the same time as the first public release of Java. So it's not a recent language.
"has the speed of a method call been a primary factor in scalability in your experience?"
Yes, yes it has. But here is the real crux for me - why can't Ruby advocates just admit that it's slow? Why is the Ruby community threatened by the accusation? Why do Ruby fans try and dismiss this fact instead of acknowledging it and moving on?
"Ruby was released in 1995, around the same time as the first public release of Java."
Point taken, I was incorrect. However, if that it is true I don't understand why a performance refactoring hasn't yet occured. Java has greatly matured in that time. Why hasn't Ruby?
I can't speak for Ruby advocates as I'm not one. The question of whether Ruby is "slow" assumes there is some absolute scale. Certainly Ruby might be slower than Java and C#. But is it too slow?
A better question might be is it fast enough? I agree with Joel that it isn't appropriate in all cases. But I found it odd that he attacks the idea of saving developer cycles and the performance of dynamic languages in principle, yet his flagship product runs on VBScript or PHP.
Honestly, at the end of the day I don't really care what he uses for his app. I just found his argument striking and hope impressionable young developers understand that what applies to Joel doesn't necessarily apply to you. ;)
As for Ruby's maturity, while it was released in 1995, it hasn't enjoyed the popularity of Java. So my point wasn't entirely as strong as it could have been. ;) Only recently is it experiencing a true resurgence.
"I agree, compared to c#, Ruby is "slow". It allows a different way of working however. Because of dead simple memoization Ruby can often be quite a bit faster for particular coding tasks (like parsing), and it's Regex performance blows c# out of the water so it's an awesome processing tool.
In the web-sphere where request latencies and database access make up most of your request cycle time, I don't think it matters all that much. Are there exceptions? Of course, but seriously, pick out the app with a 60ms latency compared to the one with 30ms latency and I'll give you a cookie.
This "slow" argument seems to come especially loudly from the less mature Microsoft crowd (hey, I resemble that!), and yet you never hear that Ruby method calls are an order of magnitude faster than JScript, or that it puts VBScript to shame in performance.
So honestly, you could have something somewhere between VBScript and c# in performance, but more flexible by far than either. That's a price I'm happy to pay these days.
Not to mention I've seen __way__ to many posts on comp.lang.ruby about the poor performance of Ruby when it was really a poor choice of algorithm or naive implementation and was often sped up to the point where the Ruby version was actually faster than the same naive algorithm in written in C.
Not that I'm someone who can do that regularly yet, especially with no CS background, but I hope to get there someday." - http://substantiality.net/
"Instead of trying to justify away poor performance or argue that a better algorithm will make up for Rubys shortcomings, a Ruby proponent should DO something about it.
I would like to see responses to criticism of Ruby performace such as this:
X is slow in Ruby, Ive worked on it a little bit and it is now Y% faster.
Lets address the issue piece by piece and make it better instead of making ourselves look stupid by saying that performance isnt important and everyone else has it wrong."
Amen. That's taking the bull by the horns. You can read the rest on the Life Long Learning blog:
http://blog.tewk.com/?p=71
If I am not mistaken, the same "speed" arguments were originally leveled at Java.
While I need to go back and reread Joel's post I absolutely disagree with this statement. If building an enterprise level application one needs to use the best tool for the job - not shoe-horning their existing knowledge into a project's form. If a language isn't 100% up to a task work arounds and hacks are ok IF on smaller projects. Learning something new is a small price to pay when compared to the cost of making an enterprise level mistake.
The problem with a relatively young platform is that experience can be very hard to come by, particularly if pitfalls of the language (such as scalability) have yet to be fully explored. That said, I have little to no experience with Ruby as a platform - maybe it is as simple and efficient and easy to learn as everyone makes it out to be. Me, I'm still stuck in C++ land ;).
Commenting has been disabled for this entry.