Catalyst vs Ruby on Rails
|Catalyst||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.
- Ruby on Rails sites directory, Top 100 Rails sites by Alexa traffic rank
- Sites powered by Catalyst
- sites powered by Catalyst vs. Rails, according to AppliedStacks:
- cafe24 article view api
The Catalyst documentation is currently undergoing reorganization at http://catalystframework.org/, 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.
In an interview with RadicalBehavior.com, 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
Perl is said to make easy things easy and difficult things possible.
RoR makes easy things very easy and complex things very difficult:
(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.)
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.
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
Catalyst can be a nightmare to install due to the large number of CPAN modules used in Catalyst. If a single module is broken, then Catalyst is likely to be broken, and the probability of a problem rises dramatically with the number of modules included. If the probability of any module being broken is only 1% (0.01) and 300 modules are installed, the chances of at least one module being broken exceed 95% though the CPAN tester fail rate has never been higher than 15% and a quick release cycle means the ratio is often less than 1%.
Another interesting aspect of this Catalyst flaw is that the Catalyst developers can never guarantee that any given build will work or that a build will survive updates.
 Application development speed
Rails is famous for its very rapid development of simple applications (Creating a weblog in 15 minutes).
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
Since Ruby doesn't have any specific facilities for managing Unicode strings, Rails' support for Unicode is not yet mature.
Perl supports Unicode natively and so does Catalyst. 
Catalyst can be debugged remotely with ActiveState Komodo IDE, or locally with the built-in perl debugger. Every Catalyst application is generated along with a test script. Catalyst has built-in logging and can be integrated with Log4Perl.
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.