I did a lot of Perl CGI.pm stuff many years ago. What's the state of Perl for building web apps? Is it comparable to Python or Ruby? Where should an old Perl program start these days?
I've been using Catalyst for years now, for everything from AMQ Consumers which run warehouses to data analytics tools, to simple front-ends. Mojolicious looks promising, Dancer looks ... well, it does what it says it does, even if I don't see much point in that :-) Being Perl, there are a gazillion plugins for doing what you need that are well tested, and well documented, on the CPAN: https://metacpan.org/search?q=Catalyst
Template Toolkit is used almost exclusively for templating, although being Perl, there's lots of ways to do it (including Mason, which is a bit more PHP-esque).
All frameworks (ish) play nicely with Plack, which is a straight rip-off of Rack, but of course being Perl, there are a gazillion well-documented, well-tested, and sensibly installable plugins for it: https://metacpan.org/search?q=plack%3A%3Amiddleware
And then there's Moose, which provides a sane interface to the mind-boggling flexibility of the Perl object-system 'hack': https://metacpan.org/module/Moose
Programming in Perl on the web has never been as fun as it is today, and you'll find mst (who's a member here) was a lynchpin in most of the projects that made that true.
People talk about Perl being a glue language, and that's absolutely right: with CPAN, it's the ultimate mashup tool when you need it to be. It supports functional programming, Moose has made OO with it awesome, and it has a testing culture second to none.
I wouldn't expect Moo to gain you much over Moose in terms of runtime performance, except in the very simple cases where Moo can use Class::XSAccessor instead of generating a perl accessor method. What you probably want instead is to profile and selectively remove type constraints - perhaps only for runtime but not for the test suite. Consider:
package MyApp::AssertIsa;
use strictures 1;
use base qw(Exporter);
our @EXPORT = qw(assert_isa);
sub assert_isa { $ENV{SOMETHING} ? @_ : () }
and then
use Moose;
use MyApp::AssertIsa;
has foo => (is => 'ro', assert_isa(isa => 'Bar'));
and flip the relevant env var for your test suite (or perhaps use one of the test harness env vars to trip it automatically for t/)
Performance issues with TT? Yowza... I am assuming you're using the XS version, helping it cache, have used a profiler to confirm that's really where it is etc. You must be serving a dramatic amount of dynamic traffic!
TT performance really can be a bitch. When I'm profiling Catalyst apps to improve performance I pretty much always assume that the first set of hotspots I'll find will be either Template Toolkit or waiting for database queries. The controller code and the Catalyst stack itself very rarely show up noticeably - and I'd suspect that Catalyst being the heaviest (or most featureful, depending on how you want to lookat it :) of the currently popular frameworks that that's likely to be true of everything else as well.
What's the right perl module to use for queue based worker stuff these days? I like rabbitmq, but unless there's something I'm missing, AMQP support in perl seems a little sketchy. Is STOMP the way to go? Or should I just build 0mq workers off mongrel2 and roll my own solution with POE or something? I kinda feel like Perl is falling a little behind in this space, but maybe I'm just not seeing what everyone else is doing.
I'd suggest also adding miyagawa to that list for Plack, cpanminus and Carton ... but then if we start adding people we'll never stop. I've given out hundreds of commit bits over the year just to the projects we provide hosting on http://git.shadowcat.co.uk/ for - CPAN's a big big place and that never ceases to make me happy.
CGI isn't fun. I understand legacy code that runs on it, I don't think developing new web apps with it is the right thing to do, there are plenty of amazing frameworks which make perl web programming fast, powerful and fun again:
You have Catalyst (full on MVC framework, you can compare it to Rails), Dancer* (micro-web inspired by Ruby's Sinatra) and Mojolicious to name a few.
I see that it's looking for a special file named Perloku and then expecting to execute that. Would it maybe be better to look for a Makefile.PL, use that to build, and then work with the standard Procfile system that Heroku has? That would be altogether more flexible.
You could also mandate using Carlton[1], which someone downthread mentioned as "bundler for perl". It's alpha at the moment, but that shouldn't stop anyone from using it.
Maybe 80, maybe not, it will run on port $PORT which is provided at runtime by Heroku. Practically you do not need to worry about it, Heroku will take care to route the request from port 80 on the outside to port $PORT at the dyno level.
