Perl and Raku: Best Frenemies

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 newsreader. 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;

At 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:

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 in addition to 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 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 DWIM-y 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 from 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.