Hacker News Reader

Comment by oomkiller | Hacker News Reader

I think anyone who has any depth of experience with Ruby can attest to the flaws it has data-intensive tasks. Thats why many of us just drop down into another language when we need to get something done efficiently. Ruby's clarity and conciseness make a lot of sense when writing views, controllers, and models, but don't have the same effectiveness in a background process that needs to be written and forgotten about.

Unless there are some major changes in Ruby (MORE than 1.9), I believe that it will be relegated to simple web applications, and never really be good at processing tons of data.

And honestly, isn't Ruby really just about prototyping? I admit, its great for startups who have nil for cash that need to get something written QUICK (to get money from investors), but once you cross that threshold, why not write it over with a language designed for efficiency?

View on HN

This really hit home for us when we started messing with TweetRex. It was my first project in Ruby and things seemed to go well -- the language has nice syntax, good selection of libraries, the prototype was done fairly quickly...

...and then I had to rewrite 80% of it in C++ because of the horrible threading, slow string manipulation and high memory usage.

It was still an interesting experiment, and I intend to continue to use Ruby for stuff where performance doesn't really matter, but I was surprised to learn so vividly that the Ruby bashing that I'd assumed was oversold was in fact pretty much spot on.

I'm not a ruby dev, but could you be more specific? Assuming you are refering to syntax, not speed: how is it good for prototyping but not "data-intensive tasks"

One example: Ruby has slow IO and text-processing capabilities. I sometimes write pipeline tasks in Ruby or Perl. i.e. while line = STDIN.gets; puts transform(line); end. Typical disk bandwidth is 2MB/s in Ruby, and 25-120MB/s in Perl, Java, Awk, or C.

Beyond that, a lot of the metaprogramming features that make Ruby cool are also expensive when done repetitively.

Also, Ruby's threads REALLY suck. And it has impossible to track down memory leaks in the interpreter. Ask mojombo about fun with those.

All of the Ruby runtimes are unreliable (buggy) and very slow. Ruby syntax is perfectly good for "data-intensive tasks", but the current runtimes are not.

How does JRuby's implementation compare to Scala's, though? I've been pleased overall with Scala, but I've not had much JRuby experience, so I'm curious.

JRuby's a pretty solid implementation. It's generally faster than MRI 1.8.x, and has the benefit of quality threading. I think Scala is probably ahead, because Scala has the benefit of being-more Java-like than JRuby, and is therefore easier to implement.

For my serious apps, I typically write the front end in JRuby on Rails, and migrate code back into Java as it stabilizes and/or needs more performance. Works great for me!

I'm doing this at my current job as well. Jruby is great!

Data-intensive tasks that you do every day, or every hour, or every minute, require efficient execution above all else.

Prototyping tasks require efficient programing (as in, the act of putting the program together) above all else.

Ruby excels at the latter, but not (yet) at the former.

Reply on news.ycombinator.com