In parts one and two I took a look at the differences and similarities between Ruby and Perl, and I think I owe it to everyone to publish a brief conclusion. My basic feeling is that while Ruby is a fantastic language, the following are a few reasons I won’t be abandoning Perl any time soon.
Proven track record
Perl has been in serious use since before Ruby was even a murmur on the internet. It has a long history of serving its purpose well and quite a list of accomplishments: everything from powerful, dynamic websites to utilities supporting the daily operations of large companies. Its performance and reliability have been proven over and over again.
Open source community and CPAN
The Perl community is active, friendly, and full of very intelligent people. As evidence of that I submit the CPAN, the Perl Mongers groups that can be found around the globe, and the different Perl mailing lists that gladly offer help to anyone seeking it.
mod_perl
Anyone who has used mod_perl can attest to the flexibility and power it gives developers. I have been involved in using it as a platform to seamlessly integrate custom Perl authentication and navigation with third-party, closed-source web applications written in completely different languages. Mod_perl is a serious tool that I would have a very difficult time leaving behind.
2 Comments
Thanks for the perl vs. ruby posts. I enjoyed them.
regarding mod_perl, I’m frustrating about the difficulty to deploy it. It is a rare site to find in a mass-hosting environment, can use a fair bit of persistent memory, and generally requires configuration that can’t be automated.
Maybe FastCGI is a middle ground. I haven’t explored it much. PHP seems to have found a decent balance of good performance without the extra configuration or hosting issues with mod_perl.
While I am also sticking with Perl over ruby, and also appreciate and use mod_perl as a tool, I suspect there are easier ways to build high-performance websites than with mod_perl.
Mod_perl is not a good fit for every web application, as you mentioned, and does require more memory and configuration than several alternatives. What it does do is give complete control over each phase of Apache, which I have found is extremely valuable in complex systems of applications. FastCGI just can’t do the sort of things I’ve been involved with using mod_perl.
I recently started using a bit of PHP to simplify maintenance on a small site, mainly because it is so easy to deploy in a shared hosting environment. So far it has been working well. FastCGI might be an option but I haven’t spent much time with it, either.