Is Ruby really as great as everyone says?

June 16, 2005 3:39 AM

Everyone seems to love Ruby. But does it lend itself to web development, and is it "polished" enough to be used as one's primary language?

It seems that every time I see someone mention Ruby or the web framework written around it, Ruby On Rails, people convulsively gush with admiration for the language. I don't think I've ever heard a single negative comment about it.

Obviously, this epidemic infatuation has piqued my interest, so I've been reading about the language. It does look pretty powerful and easy to use, but I haven't been able to determine whether it's well suited to web development, and whether it is "polished" enough to replace PHP as my primary language. My website, currently written in PHP/MySQL, is fairly extensive, and it would not be a trivial task to port everything to Ruby, not to mention having to give up the familiarity I've attained with PHP and start getting comfortable with a new language.

However, I'm currently in the process of rewriting my site with a more object-oriented approach, and I'm finding myself frustrated with PHP's unwieldiness in that area. PHP5's OO is much better than previous versions, but I'm still frustrated by its limitations. So Ruby is obviously appealing, and I'm tempted to switch to it. But is it developed enough to be worth the commitment? Is it stable enough, fast enough, does it have enough support libraries available, etc? Or is it merely a curiosity, a fun language to play with, but not ready for 'prime time' yet? Do any of you code in Ruby as your primary language?

posted by TheCowGod to Computers & Internet (21 answers total)

I think there are plenty of people out there who don't love Ruby, and just tune out when people start gushing about it, cause they've heard it all before. That said, you're right in that Ruby does not inspire the fear and loathing that say PHP or Perl would.
posted by grouse at 4:02 AM on June 16, 2005

Granted, I haven't spent all that much time with it (yet), but from cursory glances at documentation, I don't think it's that mature.

While fun, and you might be able to have a hybrid type site (not sure why you would), I would still wait for more functions and libraries prior to hopping onto the bandwagon.

Right now, I personally believe it's popularity largely stems from it's relatively easy-to-implement AJAX functionality. If you're looking for something similar in PHP, you could always check out SAJAX (the site is not always reachable for some reason).
posted by purephase at 4:47 AM on June 16, 2005

I used Ruby for a while. It's really slick, and I love (in particular) the built-in arbitrary length floating point math. But it's too fringe for me to really get into it much. The biggest drawback is that you'd be hard-pressed to find an employer where Ruby was a job requirement. I tried to switch my workplace from Perl to either Python or Ruby, but everyone knew Perl, and it was "good enough".

I'd say it's ready for prime time if you're working on a one-person job (or the head of a team and can dictate that sort of thing) and don't mind doing things manually. If you're used to PHP and Perl, you'll be surprised how much you miss a huge feature set (or module library) when they aren't available.
posted by Plutor at 5:07 AM on June 16, 2005

I assume you've seen this, but in case you haven't, you should check out the Ruby on Rails site. They have a list of current web apps using Ruby and people using Ruby for development. Like you, I've been taking a closer look at Ruby lately because of all the hype. As of right now, I've decided it's not right for our work environment, but it seems like plenty of other people have found a way to make it work for them.
posted by geeky at 5:35 AM on June 16, 2005

Just to follow up on what plutor said, there are quite a few people out there who swear by ruby, but very few who seem to be using it in a professional work environment. In that sense, you'd be better off picking up something like VB or python as a secondary language...

... but that said, learn ruby -- any time you sit down and learn something new, language-wise, you increase your skillz.

Out of curiosity, though, what do you see as PHP5's main limitations? It seems to me that PHP5 is just going to continue to get bigger and bigger in the web environment while python, which can be dropped in anywhere, ip-restriction free, is going to pick up a huge chunk of the scripting environment.
posted by ph00dz at 5:45 AM on June 16, 2005

Out of curiosity, though, what do you see as PHP5's main limitations?

Off the top of my head: lack of namespaces, frustratingly inconsistent function naming, an OOP model that while much, much better than PHP 4 still pales in comparison to the what's possible in Python or Ruby, etc, etc.

In that sense, you'd be better off picking up something like VB or python as a secondary language...

That's exactly what they were saying about Python two years ago - that it wasn't worth learning since no one was using it. More interesting to me is how much Ruby and Python are converging. The next major releases from both are copying heavily from the other and I've gone with Ruby (which is what I use at home when I'm not being paid to code) because the whitespace as relevant drives me insane.
posted by jperkins at 5:56 AM on June 16, 2005

Ruby is quite nice, and it has the best programming book ever: Why’s (Poignant) Guide to Ruby.

In terms of readiness: yes, it's quite ready for website development or most anything else you can do with python, perl, or any other scripting language du jour. Indeed, I'm a bit confused about what you think it might not be able to do.
posted by AmaAyeRrsOonN at 6:00 AM on June 16, 2005

Then again, not every hosts allows for Ruby webapp on the server (AFAIK), while the LAMP model is quite the norm today.
posted by XiBe at 6:31 AM on June 16, 2005

I don't think I've ever heard a single negative comment about it.

I used ruby for a while, and I really liked it. What I got fed up with (this is now two years ago, so it may not apply) was the fact that the English documentation was several major versions behind the Japanese. So, I switched back to python, and discovered that everything I had preferred ruby over python for had been added to python in the meantime. In retrospect I also think ruby code is less readable than python (or java), but that is just personal preference.
posted by advil at 6:50 AM on June 16, 2005

Ruby is quite nice, and it has the best programming book ever: Why’s (Poignant) Guide to Ruby.

I love that book! And my favorite quote of whytheluckystiff's:

Despite the surge of power you feel upon learning Ruby, resist the urge to trip others or slap them in the bald head. DO NOT LORD YOUR RUBYNESS OVER OTHERS!

The pickaxe book for Ruby is also one of the best specific to a programming language that I've ever read.
posted by jperkins at 7:11 AM on June 16, 2005

Note: my post above wasn't a reply to Advil. I've been trying to post it for awhile and Mefi was down. No snark intended.
posted by jperkins at 7:12 AM on June 16, 2005

Best answer: I have been using Ruby since it was a fringe language and, as advil says, the bulk of material was in Japanese. Ruby is no longer a fringe language, and the bit about the Japanese is no longer true (although I have to admit I wish Matz and others blogged in English).

Ruby is an excellent language. It has warts, but they are quite inconsequential. It's perfectly suitable for anything from a small script to a large system -- in other words, Ruby scales. It's not a toy language.

The standard library is large. There's also a wealth of third-party modules; use the RubyGems package system to install and upgrade packages on the fly. Third-party Ruby code tends to be readable and of good quality, much more so (in my experience) than with Perl and Python; there's something about Ruby that not only encourages cleanliness, but also attracts developers with a certain aesthetic sensibilities.

Ruby has excellent support for XP methods. Ruby users love unit tests. One thing you will find is different from the PHP world is that Ruby/Rails users have automated tests for their web applications. Your code is only as good as your tests.

Ruby's performance is not always great. Of course, there have been benchmarks showing how Rails outperforms J2EE; and Rails is, indeed, very fast. You probably won't often notice the fact that Ruby is interpreted directly from an AST. Personally, the only performance problem I've had has been with processing gigs of XML using the pure Ruby parser; if you ever need to do this, find some natively-compiled parser bindings.

Ruby is very actively developed. As with Python, Ruby is evolving relatively rapidly. Don't be surprised if new versions break backwards compatibility. Dealing with the changes not a problem if you upgrade carefully, keep an eye on the release notes, and make sure your code has good test coverage (see above). Of course, it's nothing like PHP's API hell. Ruby releases, even the development releases, are very stable.

Ruby would be my primary language if my company's software were written in Ruby; as it stands, professionally it's my second language, but in my heart it will always be number one. ;)

As an aside, I find this sentiment humorous:

... and whether it is "polished" enough to replace PHP as my primary language

PHP is "polished"?
posted by gentle at 8:08 AM on June 16, 2005

2 great buzzwords that taste great together: AJAX on Rails.
posted by mnology at 8:26 AM on June 16, 2005

Ruby is a pretty simple language that you can pick up the basics of very quickly, and Rails frankly isn't too difficult either. So why not set aside time over the next weekend or two to learn a little and work with it?
posted by ubernostrum at 8:53 AM on June 16, 2005

Response by poster: Thanks for all the responses.

gentle: "PHP is "polished"?"

Hehe, poor choice of words. I was mostly referring to the very large set of modules that come with a standard installation of PHP; in particular, its array and string functions are quite comprehensive. It's very convenient having functions available for things like array_slice() or htmlentities(). My main concern was that things like that might not (yet) be available in Ruby; I haven't found a nice comprehensive function reference for Ruby like the PHP one I linked above, so I'm not really sure what is available out of the box.

Your comments that "The standard library is large" and "There's also a wealth of third-party modules" give me a little hope, and seem to suggest that my fears may be unfounded. I'd really like to find a nice listing of available modules though.

ph00dz: "Out of curiosity, though, what do you see as PHP5's main limitations?"

jperkins: "...an OOP model that while much, much better than PHP 4 still pales in comparison to the what's possible in Python or Ruby, etc, etc."

Yeah, that's the main problem I have with it. I'm new to OOP; most of my programming experience has been in procedural languages like C. So I'm sure I'm not pushing PHP's OO model to its limits (I just recently learned what reflection is, for example), but I'm just annoyed by the clumsiness of even simple usage of objects in PHP. For example, the fact that you can't do something like

echo($photo->get_parent_roll()->get_title());

It has to be done in two lines, as in,

$parent_roll = $photo->get_parent_roll();
echo($parent_roll->get_title());

Or you can just make the photo->parent_roll variable public, so it can be accessed directly, and then you can do:

echo($photo->parent_roll->get_title());

But then you have to perform the "get_parent_roll" logic in the photo's constructor, to ensure that the parent_roll instance variable will contain a value when it's accessed. This causes a significant performance hit because every photo instantiated has to perform another DB query to fetch its parent roll, even if that variable is never accessed.

Plutor: "I'd say it's ready for prime time if you're working on a one-person job (or the head of a team and can dictate that sort of thing) and don't mind doing things manually. If you're used to PHP and Perl, you'll be surprised how much you miss a huge feature set (or module library) when they aren't available."

This seems to contradict what gentle said. I'm interested in Ruby for my personal website, so it is definitely a one-person job, and I don't have to worry about convincing other people. But I hesitate to switch from a language with such a broad set of modules to one where many of those types of things have to be done by hand, if there aren't large benefits to outweigh the cost.

I guess what I need to do is find out more about the set of libraries available for Ruby to get a better feel for what's available. I think I've got a much better understanding of the current Ruby "scene" now though, so thanks again for all the responses.
posted by TheCowGod at 9:27 AM on June 16, 2005

TheCowGod: "This seems to contradict what gentle said."

It sounds like gentle has more in-depth and recent experience with Ruby than I really do. His comment makes me want to check it out again, myself.
posted by Plutor at 10:45 AM on June 16, 2005

Best answer: TheCowGod: This seems to contradict what gentle said. I'm interested in Ruby for my personal website, so it is definitely a one-person job, and I don't have to worry about convincing other people. But I hesitate to switch from a language with such a broad set of modules to one where many of those types of things have to be done by hand, if there aren't large benefits to outweigh the cost.

Makes sense. Here's a few pointers:

* The standard library.
* The Ruby Application Archive, a registry which doesn't actually host anything.
* RubyForge hosts the projects.
* Many libraries are packaged as gems.
* The #ruby-lang channel on the FreeNode IRC network is very helpful. Several "big" players in the Ruby scene hang out there. (Matz listens, and everyone go crazy when he suddenly starts participates, once in a blue moon.)

TheCowGod: It's very convenient having functions available for things like array_slice() or htmlentities()

Ruby's equivalent to htmlentities() is CGI.escapeHTML.

As for array_slice, arrays are first-class objects in Ruby, and operations on them are operators, which are really just methods:

words = ["hello", "world"]
=> ["hello", "world"]
n = 1, 2, 3
=> [1, 2, 3]
x, y, z = n
=> [1, 2, 3] # now x = 1, y = 2, z = 3
n[0, 2] # sliced 2 elements from element 0
=> [1, 2]
n[1..2] # sliced from element 2 to element 3
=> [2, 3]
n.slice(1..2) # same thing as above; the slice method is alternative to the [] op
=> [2, 3]

Since APIs are methods, there's no need to name functions according to the type they operate on ("array_slice", "array_foo"), which cuts down on the time needed to hunt down functionality; I know how time-consuming it is, in PHP, to find something in the standard library that does what you need. In Ruby, you can just do:

a.methods

and it will list every method. (You can also do ri Array on the command line, which dynamically generates documentation for you.)

Note that PHP's hairbrained arrays implement indexed arrays and associative arrays using the same data structure. Ruby distinguishes between arrays and hashes (dictionaries); both are first-class objects and are subclassable and extensible.

By extensible, I mean that the classes can be extended at runtime. For example, if you put this in your code:

class Array
def top(n)
sort.reverse.slice(0..n - 1)
end
end

...this adds the method top to all existing and future array instances, so that you can do:

myarray = [10, 3, 2, 5, 15, 9, 42, 6]
myarray.top 5
=> [42, 15, 10, 9, 6]

Take that, PHP!

I would be happy to answer specific questions you might have. Oh, and good luck.
posted by gentle at 1:06 PM on June 16, 2005

I went looking into Ruby/Rails recently when I decided I needed to pick up some basic web backend development skills. The question I had was Ruby/Rails, or actually spending enough time with Python to do something with it.

As a result, I read a bunch of Python guys trying to get their head around Ruby/Rails. The takeaway for me is that while Python as a language generally offers one way to do a given thing, creating a common idiom, Python as a platform offers lots of different ways to write a web application, and someone starting from scratch must decide whether to use any of a number of different components at each level of the web app framework stack (or whether to roll their own).

Ruby, on the other hand, has one obvious way to write a web app, and that is on top of Rails, so someone just starting out a project has an obvious unified framework to use. This reduces the number of choices they have to make, and brings a degree of integration that isn't seen when picking and choosing components to assemble a web framework in Python. It also means that someone learning Ruby/Rails has a much broader base of relevant example code to refer to, since most Ruby web applications are built on Rails, and that the knowledge they gain will be more widely appropriate when trying to tweak or extend other Ruby web applications.

I don't know much, but it sounded good to me (not that I've actually made a decision about what to use)
posted by Good Brain at 2:20 PM on June 16, 2005

The only bad thing I have to say about Ruby is that it's so totally different from every other mainstream language that it seems likely to produce some nontrivial number of people who can only program in Ruby, and those skills won't be applicable to any other popular language.

In contrast, someone who knows any of Perl, C/C++, PHP, or Java can pretty easily pick up one of the others if needed.
posted by Caviar at 4:03 PM on June 16, 2005

Response by poster: gentle, you are my hero :) Thanks for that extensive answer, and for those links. That array stuff does remind me why Ruby is so cool. I think it just might be worth switching to it.

Good Brain: "Ruby, on the other hand, has one obvious way to write a web app, and that is on top of Rails, so someone just starting out a project has an obvious unified framework to use."

Yeah, Rails does sound like a great tool. At first I was kind of opposed to the idea of using something like Rails, because it felt like a kind of "Fisher Price" solution for people who can't actually write the code themselves (I kind of suffer from NIH, and thus my blog and photo gallery are written from scratch). But as I've heard and read more about Rails, I've started to get excited about it, and I think I can get over the fact that my code won't be 100% my own :) Just this once, my ego can take a backseat to my productivity.

Thanks to everyone for clearly laying out the pros and cons of the language. I think I can now make an informed decision about it. I suppose I'll install Rails and try building my photo gallery or something and see how things go.
posted by TheCowGod at 6:04 PM on June 16, 2005

TheCowGod, you're very welcome. Incidentally, although I understand the sentiment, there's nothing "dumb" about Rails; it doesn't really write code for you, it just props up your code with the framework bits that you don't want to care about. It does this very well, but it doesn't turn you into a star programmer; anyone thinking they can do a proper app with Rails without doing any serious programming is in for an unpleasant surprise. It's not Visual Basic.

Another thing to keep in mind is that Rails is just a collection of components that play well together. You don't need to use all of it. You can use Og instead of ActiveRecord (Rails' object-relational database mapping layer) if you like; some people consider it to be more flexible and powerful than AR. Or you can use XSL or Amrita some other framework to render pages, instead of Rails' default ERB (Embedded Ruby). You don't have to buy the whole package.

Caviar: In contrast, someone who knows any of Perl, C/C++, PHP, or Java can pretty easily pick up one of the others if needed.

I disagree. Ruby is, of course, Turing-complete. It's an imperative language which is not terribly different from most other languages out there -- it's just an evolutionary upgrade. Ruby has the footprints of precursors such as Smalltalk, Perl and Objective-C all over it.

Your statement would make sense if Ruby were some kind of paradigm shift, or if Ruby taught bad habits that ruined your ability to do well with other languages, or if Ruby didn't cover modern computer engineering principles, or somehow taught you absolutely nothing you could apply to other languages.

But the biggest problem with Ruby programmers and their ability to tackle other language is, simply, that after having used Ruby, they don't want to; going back to a language such as C is painful once you've had the Ruby "eureka" moment; but that's not really a problem as much as a natural emotional response.

A newbie starting out with Ruby will not suffer irreparable brain damage. Contrast, if you will, Ruby with C, which is weakly typed (as opposed to Ruby, which is strongly -- though dynamically -- typed), provides arbitrary byte pointers, and a bunch of other minor gotchas, all of which means the compiler lets many common programming pitfalls pass unnoticed.

Or consider PHP, which doesn't really teach anything except how to avoid glaring design problems in the language. (PHP is the new Basic, really; the language for non-programmers who, desperate to meet their end goal, will pummel themselves and everyone on the net with their painful, brick-like lack of competence.)

In fact, because Ruby is so high-level, it's a great teaching language; students don't need to understand so much before they can get productive: "n = 1" (itself a complete Ruby program) is such an obvious starting point, whereas with "int main(char* argv) { int n = 1; return 0; }" there are so many things to explain (or ignore) before you can get to the "n = 1" bit. Or there's "public class Main { public static void main(String[] args) { int n = 1; } }". I don't envy the teacher who has to start with that.

Ruby programmers aren't stupid, either -- there are plenty of us who use all sorts of languages.
posted by gentle at 3:56 PM on June 17, 2005 [1 favorite]