A subjective comparison between Perl and Ruby

February 1st, 2008 at 5:36 pm

The goal of this article is to examine whether it’s worth for me to switch to Ruby as my main programming language, a position currently taken by Perl. As the title states, it is subjective – in that it presents my personal opinions and targets my specific needs.


First, some background. For many years now, Perl is my main go-to guy for programming tasks. As a hardware engineer, my “programming tasks” are not enterprise-level apps distributed for the use of thousands of customers, but rather support programs and scripts whose main customers are myself and my colleagues. Sometimes these programs have GUIs, sometimes they’re even web-based, a lot of times they interact with other (mainly C++ for performance) programs, but most of them are scripts. Whenever some script has to be written for text manipulation, or a simple program for controlling some piece of embedded hardware, I turn to Perl. In size, these programs range from one-liners to several thousand lines of code (KLOCs).

Also, I must add that my platform at the time being is 100% MS Windows. In my previous job, I worked on UNIXes (Linux, AIX, Solaris), where Perl blends much better in the environment. But now I have to work with what I’ve got, and Windows is the platform. This means that I use ActiveState as the Perl distribution and have a keen interest in GUIs.

I’m always on the lookout for new tools and technologies to learn. Around two years ago, I decided to give Ruby a try, since I began hearing more and more about how cool it is. As I’m constantly lurking in the Perl community, so what gave me the push was seeing how several Perl hackers whom I respect recommend Ruby as a good future direction.

Anyway, in my last attempt, after a brief flirtation Ruby I decided to go back to Perl, as I found Ruby still not mature enough to be my go-to guy, mainly because of the lack of documentation, suitable libraries and the much smaller community.

Today, I decided to examine Ruby again, by first publishing a thorough comparison between it and Perl, in order to help myself make a learned choice.

First things first – the language core

In my opinion, Ruby’s core is superior to Perl. Not much to think of here. And I’m definitely not one to be called a “Perl basher”. I like Perl, I like its syntax, I like programming in Perl. But Ruby is better.

Ruby is everything Perl is, and more. You can write any Perl code in Ruby, in a very similar way, but Ruby offers several definite improvements. Here are a few I deem most important:

  • Object-orientation from the ground-up. Personally, I feel that while OOP is not the silver bullet, it helps in keeping large bodies of code maintainable. Writing OO code in Perl is painful, in Ruby a pleasure.
  • Convenient, built-in exception handling.
  • The support for functional features is better than in Perl. Blocks, procs, lambdas, and all that. I feel very grateful to Ruby for providing convenient means of replacing several of the things I previously thought require the power of Lisp macros.
  • Metaprogramming, better support for code generation and embedded DSLs.

So there’s no question here, at least for me. Had everything else been equal, I would certainly pick Ruby. Alas, things are never so simple.


According to the shootout, Ruby is 4-5x slower than Perl on average. This is not a major difference – I wouldn’t use Perl for heavy number crunching anyway. Besides, Ruby has an alternative virtual machine named YARV that should enter service any time now™, and is expected to improve the performance by at least a few 10s of %s.

When you need high performance, you’ll have to resort to C/C++, and both Perl and Ruby have good bindings for these languages.

Documentation and libraries

I place these two together, because I think they’re very much related. The sample people who spare the time to write useful modules, also write good documentation for their and others’ modules.

In this section, Perl wins big. Perl’s library of code, the mighty CPAN, is incomparable. Maybe Ruby is not far from Perl in popularity today, but this is a recent event. For many years, Perl was more popular by orders of magnitude, and accumulated a huge library of shared knowledge.

Documentation in the Perl world is also better. Funny, because I find the RDoc to be much better than POD. Documenting Ruby code in a standard way is far simpler and more pleasant than with Perl – where embedding POD feels like programming in the 80s. But yet again, Perl’s huge lead over a long time ensured that most of the libraries are quite well documented and there are tons of examples and snippets to be found online. Ruby is catching up, but this will take time.

Just one example: XML handling. Ruby’s canonical solution is REXML – a slow, unconvenient API with appalling error handling. I was so disgusted by REXML when writing a Ruby app a year ago that I switched my data format to YAML. Perl has numerous excellent solutions for XML parsing and generation, right in the standard distribution. Rubyists ported XML::Simple, but it’s based on REXML, which leaves it with all the deficiencies.

A disclaimer must be made here, which also applies to the “community” section. I’m concerned mainly with the English-speaking community. For Perl, there is no other. But for Ruby, there is. Ruby is an immigrant from Japan, and has a large and vibrant Japanese community behind it. It means that there are a lot of Ruby modules without any English documentation, which is a real pity. Even if these modules are terrific, there’s no way for those of us who don’t understand Japanese to enjoy them.


A community is extremely important in our connected age. A large, smart community means quicker answers to questions, more libraries and documentation, and just a place to share wisdom and learn new tricks.

The Perl community is just amazing. In football1, it is often said that the home crowd is the team’s 12th player. The Perl community is something like that. Perlmonks is the best programming language community on the Internet, period. Any question you have will be promptly answered by super-smart Perl hackers, some of whom seem to have little other interest in life than in providing detailed, well researched answers on Perlmonks. It’s also one of the best places I know of to discuss general “meaning of life” questions in relation to programming, i.e. comparing paradigms, discussing future directions, and so on.

Ruby doesn’t have anything of the kind. What it does have is a mailing list / forum / Google group2. When I tried Ruby the previous time, the situation was worse – the group was less active and the connection between the various channels wasn’t working well, creating fragmentation. Now, however, things seem to be better. The folks in the list are friendly and questions get answered quite quickly.

And still, Perl wins here. Someone should really create a Rubymonks – I think it would give a great boost to the community.

Momentum and future directions

This issue is difficult to define exactly, and hence I will digress to a little philosophizing. A metaphor might help. Consider two employees. One is 45, very smart, been-there done-that kind of guy. Everything he’s ever done, he can do again easily, quickly and soundly. However, he’s reluctant to learn new technologies, and sometime hints that he might retire early. Another is a whizzy 25 year-old. He doesn’t have so much knowledge accumulated, but he’s an excellent hacker and can learn very quickly. He’s eager to enter any new area and signals that he’ll stay in the company for a long time.

Lately, I feel that Perl is the old guy and Ruby the young guy. I will try to defend my point:

Ruby seems to be having much more momentum behind it now than Perl. New technologies are more likely to be implemented in Ruby than in Perl. New books on programming are more likely to be written with Ruby than with Perl, and most importantly, fresh hackers are much more likely to join the world of Ruby than the world of Perl.

The last point is crucial. Perl has several excellent people working with it, who are well known throughout the community. The problem is, it’s pretty much the same people of years ago. In Ruby, on the other hand, names of prolific and talented hackers constantly pop up – they push the language, with its libraries and community fast forward.

For example, take the Textile markup language3. It’s quite new, and it doesn’t surprise me that Ruby has a better library for translating it than Perl. RedCloth, written by the amazingly prolific Ruby hacker _why supports Textile better than the best Perl library out there, and no one seems to be fixing the situation in the Perl world.

The same can be said for YAML – the parser for which was also written by _why, first for Ruby, and only later ported to Perl.

Take the bindings to Wx and Qt – the two most popular cross-platform native-looks GUI frameworks. Ruby has the better bindings for both. True, Perl’s integration with Tk is unrivaled in the Ruby world, but this only proves my point – Perl is excellent in everything old, but Ruby is quickly gaining in the newer technologies. While for a GUI I‘d still use Perl/Tk, I’m watching wxRuby, drooling at its pretty native widgets and controls.

I can only mention Ruby’s strongest card – the Rails framework, in passing, because I have never used it.

Take alternative implementations as another example. Ruby has Rubinius, JRuby, IronRuby, Ruby.NET, what does Perl have ? JRuby and IronRuby are particularly interesting ventures, since they are backed by the enterprise. JRuby’s developers were hired by Sun to create a natural binding to Java on the JVM, and IronRuby is being deveoped by, no less, Microsoft’s Dynamic Language Runtime team, to bind it to the .NET framework. At last, the big two enterprise solutions – Java and .NET realized the importance of dynamic scripting languages, and did they choose Perl ? No, they chose Ruby4.

So why does this happen ? Why is Perl stagnant while Ruby is stronly moving forward5. Is it only because Ruby’s core is better ? Is it because of Rails ? IMHO there’s another reason, and that is Perl 6. With it hovering around, no one really wants to improve Perl 5 any more. Perl 5.5 was released one year after 5.4, 5.6 was released 20 months after that, 5.8 took 28 months, 5.10 – more than 5 years. Do you notice the tendency ?

Recall the old vs. new employee metaphor. Is Perl 6 the reason for Perl 5′s stagnation – I doubt it is, but it is definitely a factor. Just how much motivation would you have working hard on somethinig you know will be thrown out soon. And now imagine this soon lasts for years and years6.


It’s about time to conclude this rant. Which should I choose ? Should I replace Perl as my go-to guy with Ruby ?

The answer to this question is still no, but this time with a reservation. I enjoy writing Ruby code more than writing Perl code, at least until I ran into a piece of horrible documentation or a missing library which Perl has since 1995. But at the core, Ruby is better. And while the core is practically impossible to change (see how long Perl 6 is taking) all the peripherials are easier. In the past two years, Ruby has closed many gaps on Perl in terms of documentation, libraries and community. I think that with the current trends continuing for another two or three years, Ruby will overtake Perl in popularity and will become an all around better solution.

1 Real football (i.e. soccer in the US).

2 They’re all linked. I use the Google Group interface because I find it the most convenient.

3 The one I’m using for writing this article.

4 Well, there’s also Jython (not backed by Sun, AFAIK) and IronPython (backed by MS). But this article compares Perl and Ruby, which IMHO have a somewhat similar philosophy that is a bit different from Python.

5 According to the TIOBE index, Perl is currently at 5.4%, down from 8% 5 years ago, while Ruby is 2.3%, up from 0.25% 5 years ago.

6 Perl 6 was announced on July 19th, 2000.

Related posts:

  1. Book review: “Programming Ruby, 2nd Ed.” by Dave Thomas and Andy Hunt
  2. Logical operators in Perl and Ruby
  3. ruby
  4. Book review: “The Ruby way” by Hal Fulton
  5. Book review: “Ruby Cookbook” by L. Carlson and L. Richardson

13 Responses to “A subjective comparison between Perl and Ruby”

  1. matthewNo Gravatar Says:

    I don’t think Perl and Ruby both have good C/C++ bindings. Perl’s bindings suck really bad. XS is a nightmare. Part of that is because of Perl’s non-OO nature, so you have to deal with stack and type issues in weird ways. Adding to the confusion XS is not C, it’s some weird hybrid and has a steeper learning curve.

  2. Isaac GouyNo Gravatar Says:

    “Besides, Ruby has an alternative virtual machine named YARV …

    YARV compared to Perl

  3. chromaticNo Gravatar Says:

    I think you’re missing two points.

    First, if you want to call Perl stagnant in the past few years, you have to ignore the amazing growth in the CPAN. You probably shouldn’t do that. One of the main design goals of Perl 5 was to allow Perl to evolve strongly without centralized control, and it’s done so.

    Second, when it comes to Big Company Support, if it weren’t for Rails, Ruby wouldn’t be anywhere. Think back three years, when the dynamic language of choice for companies such as IBM and Sun was PHP. Look at JSR 223. (You might also ask yourself why, if a consulting company such as ThoughtWorks is so good at identifying powerful and useful new trends, it took them almost 20 years to realize that dynamic languages were useful. If you want to feel very generous, call it ten years.)

    Big Company Support is often fickle, slow, and wrong. I don’t rely on it as a measure of technical merit.

  4. elibenNo Gravatar Says:

    matthew: There’s Inline::C for simple uses. Also, I find the bindings to Win32 DLLs (Win32::API in Perl and Win32API in Ruby) easy to use when you don’t need a tight integration.

    Isaac Gouy: thanks for the tip, I’ll link to it.

    chromatic: I meant stagnant in the sense of popularity. CPAN will probably keep growing anyway. And enterprise support is very important IMHO – it gets smart people to work on improving these languages full-time, with pay. Imagine what happens if a few talented hackers will now be getting paid for working on Perl 6 full time. How long will it take to finish ?
    And Rails’ donation to this interest isn’t very relevant, as long as the interest exist. Rails came to the market in the very right time – when people needed to develop dynamic websites and got with with PHP’s ugliness.

  5. tomasNo Gravatar Says:

    For/on windows i use ruby-gtk / ruby-gnome

    It works and looks much better than tk IMHO :)

  6. Matt S TroutNo Gravatar Says:

    Actually, perl6 stopped slowing perl5 down about three years ago, when the perl5 community went “right, we’re bored now” and went into overdrive adding new stuff on CPAN. The core interpreter is being developed slowly, certainly, but that’s because we don’t -need- it to add features.

    For example -

    – The Moose meta-protocol and object orientation syntax entension library provides a full metaprotocol, a roles system, introspection, nice syntax, CLOS-style method modifiers and still handles multiple inheritance too
    – As far as exceptions go, Exception::Class is getting steadily more popular and provides nice sugar that still fits in with the perlish style
    – Markdown support is getting back on track – Tomas Doran is fixing up Text::Markdown -and- Text::MultiMarkdown, scraping every test he can find and passing them in between adding freatures
    – And as for DSLs, well ruby’s “look I can call a method without parens” doesn’t really excite me – for declarative syntax Object::Declare by Audrey Tang does rather well and there’s work in hand to be able to add new language keywords without source filters – see Method::Signatures for a bleeding edge but working example

    And all of these things work as far back as perl 5.8.1 – which is why none of us really worried about how long 5.10 took. We’re also attracting new developers at a reasonable rate – I’m 24 and quite a few of my community co-conspirators are younger. Perl’s not dead by a long shot, we’re just not so into loud self-promotion when there’s working code to be written …

  7. crayzNo Gravatar Says:

    Try Hpricot for XML parsing, prefer it to REXML

  8. 3legcatNo Gravatar Says:

    Why not Python? It’s nice to work with, mature with a large user base and lots of libraries, interfaces easily with C/C++ and is also faster then either Perl and Ruby. More importantly, there’s are a lot of energy and momentum behind it. That’s a lot like the younger employee you described in your blog entry.

  9. chromaticNo Gravatar Says:

    Heh. Python’s not faster than Perl in many benchmarks I’ve seen, its user base is smaller than Perl’s in every measure I’ve seen, and it doesn’t have lots of libraries compared to the CPAN. I suppose if you like it despite that, it’s a fine language… but I’ve never heard any of those put forward as serious advantages of Python if you look at the evidence.

  10. Alexandr CiorniiNo Gravatar Says:

    what do you think about Catalyst and CGI::Application?

  11. catoNo Gravatar Says:

    Well, sometimes you can improve Ruby performancewise – a bit!

    Sieve of Eratosthenes in Ruby


  12. ripper234No Gravatar Says:

    “When you need high performance, you’ll have to resort to C/C++, and both Perl and Ruby have good bindings for these languages.”

    Not really relevant to the most of the article, but I’ve seen several projects aimed at high performence not choose C/C++.

    Java and C# are more then up to the performance tasks, except maybe for realtime programming.

  13. JendaNo Gravatar Says:

    Textile markup language? That’s a pretty bad example if you ask me. Let’s see, what the heck is “Textile markup language”, google, wikipedia … aaaaah, yet another of the thousands simplified markup languages used originaly by some blogging or forum software. Now, how’s that new technology? This particular markup was first implemented in PHP … well since it was part of some PHP forum, it’s no big surprise. Then it was implemented in Ruby … I guess someone wrote his/her own forum and wanted to use the same syntax. And only then, long after, someone implemented this particular syntax in Perl … I guess it was the first time someone wrote a new forum from scratch and was looking for a syntax to support.