Catalyst vs Ruby on Rails

From WikiVS
Jump to: navigation, search

Catalyst Ruby on Rails
Ruby on Rails

Catalyst and Ruby on Rails are Model-view-controller web frameworks written in Perl and Ruby, respectively. Catalyst is renowned for flexibility and for enabling the use of over 12,000 Perl modules available on CPAN. Ruby is famous for its short learning curve, application development speed and large, easy to use Gem packaging system.



The Catalyst documentation is currently undergoing reorganization at, which is going to be powered by the Catalyst-based wiki solution mojomojo. However, the most up-to-date Catalyst's documentation still resides on CPAN. At the moment, there are two books on Catalyst. While the first one received mixed reviews, the second book, The Definitive Guide to Catalyst: Writing Extensible, Scalable and Maintainable Perl–Based Web Applications, was released in July 2009 and has so far received 5-star reviews.

RoR's documentation is organized in one place ( and there are numerous books on Rails[1].


In an interview with, Twitter lead developer Alex Payne commented:

By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework. [...] At this point in time there’s no facility in Rails to talk to more than one database at a time. [...] All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both. It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. [...] I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

This has, however, been recently addressed at slashdot.

General capability[edit]

Perl is said to make easy things easy and difficult things possible.[citation needed]

RoR makes easy things very easy and complex things very difficult:[citation needed]

Rails has a very strange learning curve. To get up a very simple website with a simple DB store, the language is great; you can get things up and running in no time, even if you're a newbie (...)

However, once you get past all the stuff Rails was designed to help you do, making it do interesting new things requires a TON of learning. All the "magic" it does, while great if you're doing things it was designed for, becomes a TOTAL headache when you're doing stuff it wasn't designed for, because all of a sudden you have to "understand the magic" in order to figure out why things aren't doing what you'd expect, and the reference documentation sucks -- several times, I've had to simply go dive into the library source code to try to figure out just what's going on, and even then, the "magic" makes it nearly impossible to easily figure out.

(Note from Paul: I've long since become a total Rails convert. Their documentation is actually fantastic at this point, for one thing, and Ruby has become my favorite language. Having gone back to use some other "frameworks", I have to admire now that Rails promotes a specific model for building apps, as I realized just how often, even with the framework, I find myself reinventing the wheel.)

Interestingly, Paul Clegg's comments are more or less exactly what I was thinking when I dropped Rails in search of something else (eventually finding Catalyst). As long as you wanted to do what the Rails developers had already thought about, you were in great shape. If you wanted to do something that the Rails developers hadn't thought of, you were screwed. I joked at the time that Rails was the most appropriately named framework, because as long as the rails went there, you could go. If they didn't, you had a long hard walk ahead of you.

Jay Kuri, CPAN contributor

The more time I spend, the more I think that Catalyst is really dedicated to working in the problem space where the most important parts aren't "done for you". Componentry is about taking away the boring stuff so that you can spend more of your time on the really chewy stuff. The only reasons you write a boring "just glue the pieces together" app in Catalyst are A) you're a beginner and you're doing it to learn the ropes, or B) you're an expert and you're so attuned to Catalyst that it hurts you to use anything else :) Of course it's the relatively easy stuff that has mass appeal, but fuckit. I'll take "lets me work minor miracles" over "super easy to use and has awesome screencasts" anyday :-P

Andrew Roland in #catalyst, 2009-Feb-09


On Debian and friends, a version of Catalyst can be installed with apt-get...

apt-get install libcatalyst-perl

For manual installs of Catalyst, using perlbrew and mcpan will give you great control of your perl interpreter, catalyst version and the versions of its dependencies.


Some Ruby features differ notably from languages such as C or Perl [2] , [3].

Application development speed[edit]

Rails is famous for its very rapid development of simple applications (Creating a weblog in 15 minutes).

Catalyst currently lacks a good set of screencast demonstrating its features. Two such resources are and Catalyst with FormBuilder screencast.



Catalyst supports a huge number of physical and virtual database backends, and different ORMs. RoR's favored ORM is ActiveRecord.

Perl/Catalyst has DBI, DBIx::Class, and Tangram which supports a large number of database backends (100+). Catalyst allows each model to be from different databases (even database sources). Some useful virtual databases exist (Amazon, Google, Excel documents, CSV files, etc.). DBIx::Class is the most popular ORM and supports features such as multi-column primary keys and character-based primary keys.

Rails supports the primary 6 database backends, although MySQL seems to be the best supported. Test and development "environments" can easily and automatically use different databases, however. Developers are not forced to use Rails' database layer, and some choose to use other Ruby based solutions. ActiveRecord is the most popular ORM for Rails. It has some design limitations in that it does not natively support multi-column primary keys.

ActiveRecord's lack of support for multi-column primary keys is important, because many-to-many relationships require a junction table, whose primary key is made up of 2 columns referencing the two tables it links. Junction tables are required in most aspects of web application design: tagging items (an item may have many tags, and a given tag may belong to many items), representing user access roles etc.

Unicode / Internationalization[edit]

Since Ruby doesn't have any specific facilities for managing Unicode strings[4], Rails' support for Unicode is not yet mature.

Perl supports Unicode natively and so does Catalyst. [5]


Catalyst can be debugged remotely with ActiveState Komodo IDE, or locally with the built-in perl debugger[6]. Every Catalyst application is generated along with a test script. Catalyst has built-in logging and can be integrated with Log4Perl[7].


Catalyst allows for easy decoupling of the model from the web application, which permits separate testing of the database backend without going through the web application. RoR fills the controllers up with logic.


Twitter status update on Perl and Rails (archive)