Look, I get it. You don’t like the Perl programming language or have otherwise disregarded it as dead.” (Or perhaps you haven’t, in which case please check out my other blog posts!) It has weird noisy syntax, mixing regular expressions, sigils on variable names, various braces and brackets for data structures, and a menagerie of cryptic special variables. It’s old: 34 years in December, with a history of (sometimes amateur) developers that have used and abused that syntax to ship code of questionable quality. Maybe you grudgingly accept its utility but think it should die gracefully, maintained only to run legacy applications.

But you know what? Perl’s still going. It’s had a steady cadence of yearly releases for the past decade, introducing new features and fencing in bad behavior while maintaining an admirable level of backward compatibility. Yes, there was a too-​long adventure developing what started as Perl 6, but that language now has its own identity as Raku and even has facilities for mixing Perl with its native code or vice versa.

And then there’s CPAN, the Comprehensive Perl Archive Network: a continually-​updated collection of over 200,000 open-​source modules written by over 14,000 authors, the best of which are well-​tested and ‑documented (applying peer pressure to those that fall short), presented through a search engine and front-​end built by scores of contributors. Through CPAN you can find distributions for things like:

All of this is available through a mature installation toolchain that doesn’t break from month to month.

Finally and most importantly, there’s the global Perl community. The COVID-​19 pandemic has put a damper on the hundreds of global Perl Mongers groups’ meetups, but that hasn’t stopped the yearly Perl and Raku Conference from meeting virtually. (In the past there have also been yearly European and Asian conferences, occasional forays into South America and Russia, as well as hackathons and workshops worldwide.) There are IRC servers and channels for chat, mailing lists galore, blogs (yes, apart from this one), and a quirky social network that predates Facebook and Twitter.

So no, Perl isn’t dead or even dying, but if you don’t like it and favor something newer, that’s OK! Technologies can coexist on their own merits and advocates of one don’t have to beat down their contemporaries to be successful. Perl happens to be battle-​tested (to borrow a term from my friend Curtis Ovid” Poe), it runs large parts of the Web (speaking from direct and ongoing experience in the hosting business here), and it’s still evolving to meet the needs of its users.

Last week I explored using the Inline::Perl5 module to port a short Perl script to Raku while still keeping its Perl dependencies. Over at the Dev.to community, Dave Cross pointed out that I could get a bit more bang for my buck by letting his Feed::Find do the heavy lifting instead of WWW::Mechanizes more general-​purpose parsing.

A little more MetaCPAN investigation yielded XML::Feed, also maintained by Dave, and it had the added benefit of obviating my need for XML::RSS by not only discovering feeds but also retrieving and parsing them. It also handles the Atom syndication format as well as RSS (hi daxim!). Putting it all together produces the following much shorter and clearer Perl:

#!/usr/bin/env perl

use v5.12; # for strict and say
use warnings;
use XML::Feed;
use URI;

my $url = shift @ARGV || 'https://phoenixtrap.com';

my @feeds = XML::Feed->find_feeds($url);
my $feed  = XML::Feed->parse( URI->new( $feeds[0] ) )
    or die "Couldn't find a feed at $url\n";

binmode STDOUT, ':encoding(UTF-8)';
say $_->title, "\t", $_->link for $feed->entries;

And here’s the Raku version:

#!/usr/bin/env raku

use XML::Feed:from<Perl5>;
use URI:from<Perl5>;

sub MAIN($url = 'https://phoenixtrap.com') {
    my @feeds = XML::Feed.find_feeds($url);
    my $feed  = XML::Feed.parse( URI.new( @feeds.first ) )
        or exit note "Couldn't find a feed at $url";

    put .title, "\t", .link for $feed.entries;
}

It’s even closer to Perl now, though it’s using the first routine rather than subscripting the @feeds array and leaving off the the $_ variable name when calling methods on it—less punctuation noise often aids readability. I also took a suggested exit idiom from Raku developer Elizabeth Mattijsen on Reddit to simplify the contortions I was going through to exit with a simple message and error code.

There are a couple of lessons here:

  • A little more effort in module shopping pays dividends in simpler code.
  • Get feedback from far and wide to help improve your code. If it’s for work and you can’t release as open-​source, make sure your code review process covers readability and maintainability.

The Perl and Raku programming languages have a complicated history together. The latter was envisioned in the year 2000 as Perl 6, a complete redesign and rewrite of Perl to solve its problems of difficult maintenance and the burden of then-​13 years of backward compatibility. Unfortunately, the development effort towards a first major release dragged on for ten years, and some developers began to believe the delay contributed to the decline of Perl’s market- and mindshare among programming languages.

In the intervening years work continued on Perl 5, and eventually, Perl 6 was positioned as a sister language, part of the Perl family, not intended as a replacement for Perl.” Two years ago it was renamed Raku to better indicate it as a different project.

Although the two languages aren’t source-​compatible, the Inline::Perl5 module does enable Raku developers to run Perl code and use Perl modules within Raku, You can even subclass Perl classes in Raku and call Raku methods from Perl code. I hadn’t realized until recently that the Perl support was so strong in Raku despite them being so different, and so I thought I’d take the opportunity to write some sample code in both languages to better understand the Raku way of doing things.

Rather than a simple Hello World” program, I decided to write a simple syndicated news reader. The Raku modules directory didn’t appear to have anything comparable to Perl’s WWW::Mechanize and XML::RSS modules, so this seemed like a great way to test Perl-​Raku interoperability.

Perl Feed Finder

First, the Perl script. I wanted it smart enough to either directly fetch a news feed or find it on a site’s HTML page.

#!/usr/bin/env perl
use v5.24;    # for strict, say, and postfix dereferencing
use warnings;
use WWW::Mechanize;
use XML::RSS;
use List::Util 1.33 qw(first none);
my @rss_types = qw<
    application/rss+xml
    application/rdf+xml
    application/xml
    text/xml
>;
my $mech = WWW::Mechanize->new;
my $rss  = XML::RSS->new;
my $url = shift @ARGV || 'https://phoenixtrap.com';
my $response = $mech->get($url);
# If we got an HTML page, find the linked RSS feed
if ( $mech->is_html
    and my @alt_links = $mech->find_all_links( rel => 'alternate' ) )
{
    for my $rss_type (@rss_types) {
        $url = ( first { $_->attrs->{type} eq $rss_type } @alt_links )->url
            and last;
    }
    $response = $mech->get($url);
}
die "$url does not have an RSS feed\n"
    if none { $_ eq $response->content_type } @rss_types;
binmode STDOUT, ':encoding(UTF-8)';    # avoid wide character warnings
my @items = $rss->parse( $mech->content )->{items}->@*;
say join "\t", $_->@{qw<title link>} for @items;

In the beginning, you’ll notice there’s a bit of boilerplate: use v5.24 (released in 2016) to enable restricting unsafe code, the say function, and postfix dereferencing to reduce the noise from nested curly braces. I’m also bringing in the first and none list processing functions from List::Util as well as the WWW::Mechanize web page retriever and parser, and the XML::RSS feed parser.

Next is an array of possible media (formerly MIME) types used to serve the RSS news feed format on the web. Like Perl and Raku, RSS formats have a long and sometimes contentious history, so a newsreader needs to support several different ways of identifying them on a page.

The program then creates new WWW::Mechanize (called a mech for short) and XML::RSS objects for use later and gets a URL to browse from its command-​line argument, defaulting to my blog if it has none. (My site, my rules, right?) It then retrieves that URL from the web. If mech believes that the URL contains an HTML page and can find link tags with rel="alternate" attributes possibly identifying any news feeds, it then goes on to check the media types of those links against the earlier list of RSS types and retrieves the first one it finds.

Next comes the only error checking done by this script: checking if the retrieved feed’s media type actually matches the list defined earlier. This prevents the RSS parser from attempting to process plain web pages. This isn’t a large and complicated program, so the die function is called with a trailing newline character (\n) to suppress reporting the line on which the error occurred.

Finally, it’s time to output the headlines and links, but before that happens Perl has to be told that they may contain so-​called wide characters” found in the Unicode standard but not in the plain ASCII that it normally uses. This includes things like the typographical curly quotes’ that I sometimes use in my titles. The last two lines of the script loop through the parsed items in the feed, extracting their titles and links and printing them out with a tab (\t) separator between them:

Output from feed_finder.pl

Raku Feed Finder

Programming is often just stitching libraries and APIs together, so it shouldn’t have been surprising that the Raku version of the above would be so similar. There are some significant (and sometimes welcome) differences, though, which I’ll go over now:

#!/usr/bin/env raku
use WWW::Mechanize:from<Perl5>;
use XML::RSS:from<Perl5>;
my @rss_types = qw<
  application/rss+xml
  application/rdf+xml
  application/xml
  text/xml
>;
my $mech = WWW::Mechanize.new;
my $rss  = XML::RSS.new;
sub MAIN($url = 'https://phoenixtrap.com') {
    my $response = $mech.get($url);
    # If we got an HTML page, find the linked RSS feed        
    if $mech.is_html {
        my @alt_links = $mech.find_all_links( Scalar, rel => 'alternate' );
        $response = $mech.get(
            @alt_links.first( *.attrs<type> (elem) @rss_types ).url
        );
    }
    if $response.content_type(Scalar) !(elem) @rss_types {
        # Overriding Raku's `die` stack trace is more verbose than we need
        note $mech.uri ~ ' does not have an RSS feed';
        exit 1;
    }
    my @items = $rss.parse( $mech.content ).<items>;
    put join "\t", $_<title link> for @items;
}

The first thing to notice is there’s a bit less boilerplate code at the beginning. Raku is a younger language and doesn’t have to add instructions to enable less backward-​compatible features. It’s also a larger language with functions and methods built-​in that Perl needs to load from modules, though this feed finder program still needs to bring in WWW::Mechanize and XML::RSS with annotations to indicate they’re coming from the Perl5 side of the fence.

I decided to wrap the majority of the program in a MAIN function, which handily gives me command-​line arguments as variables as well as a usage message if someone calls it with a --help option. This is a neat quality-​of-​life feature for script authors that cleverly reuses function signatures, and I’d love to see this available in Perl as an extension to its signatures feature.

Raku and Perl also differ in that the former has a different concept of context, where an expression may be evaluated differently depending upon whether its result is expected to be a single value (scalar) or a list of values. Inline::Perl5 calls Perl functions in list context by default, but you can add the Scalar type object as a first argument to force scalar context as I’ve done with calls to find_​all_​links (to return an array reference) and content_​type (to return the first parameter of the HTTP Content-​Type header).

Another interesting difference is the use of the (elem) operator to determine membership in a set. This is Raku’s ASCII way of spelling the ∈ symbol, which it can also use; !(elem) can also be spelled . Both are hard to type on my keyboard so I chose the more verbose alternative, but if you want your code to more closely resemble mathematical notation it’s nice to know the option is there.

I also didn’t use Raku’s die routine to exit the program with an error, mainly because of its method of suppressing the line on which the error occurred. It requires using a CATCH block and then keying off of the type of exception thrown in order to customize its behavior, which seemed like overkill for such a small script. It would have looked something like this:

{
    die $mech.uri ~ ' does not have an RSS feed'
        if $response.content_type(Scalar) !(elem) @rss_types;
    CATCH {
        default {
            note .message;
            exit 1;
        }
    }
}

Doubtless, this could be golfed down to reduce its verbosity at the expense of readability, but I didn’t want to resort to clever tricks when trying to do a one-​to-​one comparison with Perl. More experienced Raku developers are welcome to set me straight in the comments below.

The last difference I’ll point out is Raku’s welcome lack of dereferencing operators compared to Perl. This is due to the former’s concept of containers, which I’m still learning about. It seems to be fairly DWIMmy so I’m not that worried, but it’s nice to know there’s an understandable mechanism behind it.

Overall I’m pleased with this first venture into Raku and I enjoyed what I’ve learned of the language so far. It’s not as different with Perl as I anticipated, and I can foresee coding more projects as I learn more. The community on the #raku IRC channel was also very friendly and helpful, so I’ll be hanging out there as time permits.

What do you think? Can Perl and Raku better learn to coexist, or are they destined to be rivals? Leave a comment below.