My little application (10 Years Later, Only 250 SLOC) has grown to almost 500 SLOC, and it'll grow some more as I add user accounts and login. I'm happy to use Catalyst for the dynamic portions, as the abstractions and plugins are useful and reduce the amount of code I have to write.
Using modern Perl 5 for one portion of the project does not necessarily require the use of Perl 5 for all of the project.
I've long been an advocate of Perl 6 the language, so is it worth using Perl 6 for the other part of the project? The big contender is obviously Rakudo, because it is the most active project and runs on a free software stack I can debug myself. (The other possible candidate implementation, Niecza, runs on Mono, which disqualifies it from my considerations. Your personal technology choices may not be mine. I have no interest in discussing Mono here.)
I posted the other day my list of requirements to use Rakudo for practical purposes. What do I need technically?
This little app must:
- Communicate with a database. I don't necessarily need DBIx::Class for a project of this size, but I do need the ability to work with SQLite now and PostgreSQL later. Without DBIC, I'd have to do more work mapping tables and rows to objects, but the schema is simple enough it's not too onerous.
- Communicate with websites. I do need the equivalent of LWP. While I do use at least one specialty web service consumer module from the CPAN, I could as easily perform HTML scraping.
- Manage regular expressions, not grammars. Part of the project requires HTML scraping. If I were prone to overengineering, I'd write a full Perl 6 grammar for this. As it is, some quick and dirty data munging is more than sufficient right now for this proof of concept.
- Work with a decent templating system. I know there's no Template Toolkit system for Perl 6 right now, but I don't use all of TT's power. I need only a few features: variable interpolation, loops, conditionals, and subtemplates. If I had to reinvent a template system or work around it I could, but why would I want to? (I am in no mood to reinvent HTML escaping or to correct UTF-8 encoding either.)
- Work with dates and times. I use Perl 5's DateTime. Never again will I reinvent date or time handling. Never.
- Deploy easily. I use Dist::Zilla to manage bundling and testing. The simpler the work to deploy new versions and corrections, the more frequently I will do it. Again, Dzil does far more than I need, but what it needs I hate to give up.
Speed doesn't really matter for this application. It's a batch process which runs once a day and takes 10 seconds in Perl 5, mostly because I haven't done any work to exploit the embarrassingly parallel nature of the processing. If Rakudo ran it in ten minutes, that would be fine. (With that said, the data set will probably eventually scale by two orders of magnitude, so improving the Perl 5 version's parallelism is useful but would likely help a Rakudo version less.)
Memory use does matter, because I've deployed this application to a shared server and want to be a good citizen.
The stability of Rakudo as a target platform also matters, because I've set up this program to run without manual intervention for days, weeks, and even months. I understand that one of Rakudo's goals is to produce new and better versions every month or so, and I understand that me babysitting a Perl 6 version of this little app would provide valuable feedback to Rakudo developers...
... but I can't justify turning a fire-and-forget tiny side project into the tip of a spear intended to open the tent for further, larger projects.
I could work around the lack of most of the few modules I need. (Database access is the only real sticking point.) Yet even for a small side project—a toy project, even—with minimal needs, I find myself not wanting to use Rakudo because I'd rather spend my small side project time working on the small side project and not trying to get the technology stack beneath that small side project to stay put.
The conventional wisdom in #perl6 seems to be that Perl 6 needs more people playing with it to find bugs and more people building its equivalent of CPAN to attract more people to play with it. In my experience, Perl 6 needs something at a lower level: Perl 6 needs an implementation which provides what Rakudo Star was supposed to be. A year after the release of the first Rakudo Star, Rakudo isn't it, at least for me.
Maybe your project is different, and maybe your needs are different from mine. All I know is that while I'd liked to have used Perl 6 for this project, it didn't work out, and that's disappointing.