OK, Raku

So, Larry Wall agreed to rename Perl 6 to Raku. Here’s the quote with a nested quote in it:

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.”

This blog will soon be renamed from Perl 6 Inside Out to Raku Online, and most likely you will read it from raku.online instead of perl6.online (DNS changes are still not always that instantaneous as language renaming).

The major two ideas behind renaming is to:

• Allow Perl 5 to continue its development, and
• Avoid Perl in the name of Perl 6 to have new adopters.

There were a number of long and painful discussion rounds, and I would not say that they were human-oriented. There are still a few issues that you cannot cancel, but I am ready to reset it.

The Raku language is a great language and it is ways better than the Perl 6 as it was originally thought 19 years ago. It is not only about changing the syntax of the for loop; during the past two decades, the language design got some killing features, among which are, first of all:

• Grammars — the next level of world-standard regular expressions, and
• Features for parallel and concurrent computations (including a lot of syntactic pleasures such as reduction operator).

Even without the other features of the language, these two items can potentially attract new adopters of the Raku language.

But.

But what is missing from the rename proposal is the fact that the current Rakudo compiler is not actually production-ready. I’ll explain.

When I was promoting Perl 6, I was always mentioning that it has a compiler that can be used even in production. Indeed, it does not crash anymore (at all!), it is quite reliable, feature-complete and more or lest fast at the execution phase. But fast enough for test and joy. Not for production.

My plan for the next round of Perl 6/Raku life cycle is to:

• Establish an annual international Raku conference (having the RakuCon name in mind), and
• Initiate the compiler speed boost.

As for the conference, I propose we have the first RakuCon conference on Cyprus in May 2020, at the place we proposed for the PerlCon 2020 earlier this year in Riga. I am sure that in the long term, PerlCon and RakuCon will part, so there’s no need to wait before it happens naturally. I would prefer to force it. The presence of Raku at PerlCon is up to their organisers. From my side, RakuCon is open for Perl 5 talks (the most interesting topics are Perl 5 adopting the Perl 6/Raku features and changes in the Perl 5 compiler(s) to make it faster).

As for the compiler question, I am less confident in this area. I am confident in that if the compiler is faster, the language gets stronger perspectives.

Let me tell the truth, even if the Rakudo team will hate me once again. The Rakudo compiler is over-engineered. It has at least three layers that include NQP and MoarVM, which helped to build the compiler for the complex language, but slows up real-life applications.

I see two ways to achieve the goal (the goal is, if you missed it, to make Raku a popular programming language):

• Create a new Raku compiler.
• Learn Rakudo to produce binary or bytecode output that can be executed at machine speed. I think it is fine that only a subset of the language will be allowed here.

From the Perl 5 and the former Perl 6 community, I am seeking for help to implement the above items. In a few weeks, we will approach the companies to explain our view of Raku perspectives and to ask for supporting the conference and possibly the development. If you want to help my team, please indicate your intention.

I want to reset all previous grudges and start it over.

This is the only way Raku can prosper and thrive.

Ah, yeah, and tell me if it is Ráku or Rakú.