Larry has approved renaming Perl 6 to raku

Via this comment, Larry has said:

I am in favor of this change, because it reflects an ancient wisdom:

"No one sews a patch of unshrunk cloth on an old garment, for the patch will pull away from the garment, making the tear worse. Neither do people pour new wine into old wineskins. If they do, the skins will burst; the wine will run out and the wineskins will be ruined. No, they pour new wine into new wineskins, and both are preserved."

Unsurprisingly, it's a Biblical quote.

But what does this mean?

Well, first, it looks like raku is now going to be the official name of Perl 6.

Second, it will hopefully put to rest many of the deeply divisive arguments people in the Perl community have had over the rename. Though support for a rename was overwhelming, there was a loud minority who objected. But through it all, one thing remained clear: everyone meant well.

There's more to be said there, but I think that's enough: everyone meant well. That's something everyone (including myself), could stand to keep in mind more often. Even if someone strongly disagrees with you, they're generally meaning well and we should approach things from that spirit.

But that's behind us now (hopefully). With Larry blessing the change, it's time for us to look to the future and put the past behind us.

So what does raku offer us?

  • A powerful dynamic language with a working concurrency model
  • Gradual typing
  • Optional type inference (still a work in progress)
  • Easy creation of custom types that match business needs, not computer needs
  • A powerful OO system that leapfrogs the capabilities of most other languages
  • Grammars which make pcre look like archaic toys
  • The potential of having the fastest dynamic language due to its sound architecture

Given the amazing performance improvements made in raku in the past year (and it often outperforms Perl in many areas), and the roadmap for many more performance improvements, this is a perfect time for raku to be launched as a new language.

One of the many things I love about raku is that when I've given presentations about it, I constantly hear from developers about how feature X solves a thorny problem they have, but many developers identify a different "feature X." Raku isn't a one-trick pony designed to scratch a particular itch; it's become a robust, mature specification with a powerful implementation which gives it capabilities which far surpass many other languages. And the awesome concurrency model is icing on the cake.

But whither Perl? I've already been contacted by a reporter about what the rename means for the future of Perl and raku. I've had some developers contact me asking if we can rename Perl to Perl 7 now. I think there's going to be some interesting times ahead, but I don't know how versioning is going to work for Perl yet. There are a number of viable alternatives and I expect that debate will also be contentious.

For Perl to have a new, major release, a few things should probably happen. These assume that a major release is the time when perhaps we can break backwards-compatability.

  • Signatures must no longer be experimental
  • A solid OO system must become core
  • Deprecated features should be identified and eliminated

There's probably more, but those are just my thoughts off the top of my head. It's an exciting time and I'm looking forward to seeing what the future brings for both Perl and raku.


Now that Raku has its own name, I would like to see it create its own discrete identity as quickly as possible.

Twitter already has people talking about RakuCon as its own annual event. This is a good start.

I would like to see The Perl Foundation (aka Yet Another Society) spin off a new foundation to support Raku, with its own board of directors, its own charter, and control of its own destiny.

This allows TPF to restore its focus to Perl.

Hopefully people will interpret this as Raku moving out and starting its own life, rather than being kicked out.

  • Signatures must no longer be experimental "optional" though, should still be allowed, right?

  • A solid OO system must become core "solid"? Define. I don't think so. I think you choose between Moose/Moo and Mouse, ship it in core and move on. Unless it is believed that none of these is clear or fast enough.

  • Deprecated features should be identified and eliminated This alone would be enough to move to 7

These assume that a major release is the time when perhaps we can break backwards-compatability.

Et tu, Ovid? Whyyyyy does everyone keep saying that, why?

The whole point of Perl 6 was to be where compatibility would be broken. Not Perl 5. A Perl 5 that isn’t compatible with Perl 5 is just a lesser new Perl 6 effort. One without a good designer at the helm.[1] And one with all the attendant problems at becoming relevant from scratch – because every bit of compatibility that‘s thrown away is a chunk of existing Perl code in the world that’s thrown away which is a chunk of existing relevance that is being thrown away.

Perl 5 is not a new language. It should not be understood and maintained as one. Its development should conducted with the understanding that its built-up relevancy is an asset, not a liability.

[1] Remember what a mess the RFC process was? How incoherent the big picture? What we would get from attempts at piecemeal major reinventions of the language now is exactly what we saw there, because all of the dynamics would be exactly the same as they were then. It would be a frankenlanguage.

Leave a comment

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book!