Is generative AI killing or saving Raku?

Since my ban from the official Raku places, I don't have as many news about the project as I used to - which is a shame because apparently the last couple of months have been more exciting and turbulent than basically any time since I got involved in late 2021. The defaulting of the RakuAST in Rakudo is of course an important step towards the long-awaited language version 6.e but given my situation, allow me to be more excited about some other changes:

• two vibe-coded but ambitious Raku runtimes - Raku++ and Mutsu - popped up, started by two senior members of the "Rakuverse"
• Rakudo itself (and MoarVM in particular) started getting AI-generated code contributions - this, however, came at a cost: Timo Paulsen, long-term MoarVM contributor, left the project indefinitely over the disagreement

This article will be a compilation of thoughts and topics that occurred to me in the light of the events.

Life after Rakudo's monopoly

Originally targeting ParrotVM, Rakudo has been in active development since 2008. It wasn't the first ever runtime for Perl 6 as it was called then, but to my knowledge, it was the only one that reached "Christmas", the first official release of then-Perl 6, in 2015. The relation of Raku and Rakudo is perfectly illustrated by the names: the language got inspired from the runtime's name, and not the other way around. (Recent: the first ever "Raku weekly" has just been published, after a long history of "Rakudo weeklies", predating the whole renaming debate.)
For the longest time in the history of Perl 6 and later Raku, the following feedback loop worked:

• if you wanted to support the language, your most effective contribution was work on the only actually usable runtime, Rakudo
• since Raku didn't have much management, Rakudo development de facto determined the rules - somewhat de iure as well ("core membership" being defined as commit bit in mostly Rakudo-related repositories or chief architect Jonathan Worthington serving as pumpking) but in any case, the most entrusted members were all Rakudo developers

This situation didn't actually encourage developing a language standard independent of Rakudo - with always more work than hands, it's easy to have some empathy for not wasting time on supporting your non-existent competition. This is why I opened this issue in the first place and used to say that all actual code written is written for Rakudo (an actual concrete thing), and not Raku (a severely under-defined abstract thing only backed by Roast). The irony: as I was looking for my old issue, I saw that there is a brand new issue about the exact predictable consequences of writing code for Rakudo - which itself didn't bother to have strong backward compatibility guarantees. Raku++ also claims to "treat Rakudo as a reference".

One of the big reasons I was skeptical of an alternate compiler/runtime, even besides the humongous size of the language, was that Rakudo-compatibility would be essential and it would spoil the effort - or so I thought at least. Now this is an open question: the new runtimes try to test as much code as possible but installing some modules (running their own, self-declared test suite, usually even less definitive than Roast for Raku) is very different from actually trying to use them. To be honest, I'm already a bit satisfied that issues I have been very vocal about that were downplayed as theoretical nitpicking are now proving to be tangible issues, and also that there is an incentive to actually solve them now, which would have been the goal all along. I think Raku the language might benefit from the competition of runtimes (so far, there seems to be optimism of all parties involved, as much as I can tell) and also that the feedback loop can break now: "Raku stakeholders" won't equal "Rakudo stakeholders".

The genAI argument

I'm concerned about this LLM revolution, especially as a professional software developer. There are many things one can be concerned about, ranging from environment to employment, questions of knowledge and trust, centralisation of power, economical collapse and so on. What is getting harder to deny day by day is that well-tested, well-documented and well-functioning software can be created in ways we couldn't imagine just a few years back, as exemplified both by the new runtimes and Nick Logan's Rakudo/MoarVM patches written by Claude. Therefore I think technical (as in, "the result is not good enough") arguments are becoming less and less convincing, and even though I can empathize with quite a few moral arguments, I think there are strong "arms race" counter-arguments, as in, use the technology defensively, lest it get used on you offensively, which will happen eventually.

Referring back to the MoarVM issue about the use of generative AI, with all due respect to Timo (who, for what it's worth, I have much more personal reason to like than Nick), besides the strong despisal of LLM's and the companies invested in them, I find the argument that Rakudo will be worse off in the long run, and that it actually gets harder to find maintainers, completely out-of-touch. Rakudo, and MoarVM in particular, has been running so short of maintainers for years now, that Timo could hypothetically fork it today (or yesterday, if you will), and prove the viability of the non-gen-AI path by bringing 3-4-5 skilled developers who are suddenly interested in MoarVM; that would be a significant maintenance improvement and a strong argument in itself. To recite a classic: well volunteered.
(Side note: I'm glad this "you could at least apologize for quoting DHH" sentiment came after I had been banned anyway. It's disappointing that they are still trying to do that. DHH is a tech bro with some provocatively phrased alt-right takes, nothing one couldn't just sincerely argue against. People all across the Western world are increasingly electing people more racist and "bigoted" than DHH because the alternative is this: denial of tangible problems and vilification instead of self-proclaimed "empathy".)

I'm not an LLM enthusiast but I think the Rakudo team is doing the inevitable here. For those who are concerned that the code might become AI slop - the project barely had people who could evaluate whether the starting design was any good to begin with. There was nothing to even gatekeep. The only chance to really try and compile knowledge about the current code seems to be, ironically, to ask a coding agent to figure it out for you.

It seems to me all participants using AI for Raku development want to see the language succeed - however, the question is also if Raku, a vastly AI-unfriendly language, can be successful in a future built on generative AI. One can only guess.

Raku++ and a plan bigger than a runtime

I'm personally very curious to see where Raku++ goes. It was started by Andrew Shitov who organized several conferences for Perl and/or Raku and had concerns about Rakudo as a flagship product for making the language popular as early as in 2019. He has plenty of articles about the process on his own website but he also created a whole new Raku site with language guides, training tasks, showcases and more. He clearly sees commercial value in this project. I was surprised to find this page about potential Rakudo bugs caught on the way, quite a lot of them with lots of references and plenty of context. Seems like he is simultaneously obsoleting my former work? 😄In any case, if there is anybody within the community who has the PR skills to sell Raku as long as the technical excellence is there, it has to be him.

Having said that, there was another reason why I didn't believe in this "screw that, I'm just going to vibe code a runtime and beat Rakudo in its own game" path: I think there are genuine systemic issues in the design, and as such, it would be an attempt to fork the whole community, rather than some part of the software. Andrew Shitov has just published his second post about Junctions and Mutsu also has them listed as an argument for using Raku. I started an article about why Junctions are destined to fail back in May, I still have the draft somewhere. Let me just show one example, as a peek-in:

# "find the first value which is between 0 and 10 and is even"
sub find-valid(@list) {
  @list.first({ 0 < $_ < 10 && $_ %% 2 })
}
dd find-valid((1|222,2)); # any(1, 222) - basically anything you do with this value will cause trouble

When I came up with this example, Raku++ and Mutsu didn't even exist, yet, predictably, they both produce the same result, because Junctions are "designed to work this way". This is a language issue, not a runtime issue. I really hope I made it sufficiently hard to downplay this example as "bad use" and "deliberate poking with corner cases". Junctions are just not worth it, and as first-class values, they outright do more harm than good.

Questions

… to involved parties, that is: I think some of these answers could be interesting to many, they sure are all interesting to me.

• To the (Rakudo) core team: all in all, what do they think about these new, vibecoded runtimes? Good news or bad news?
• To the implementors of Mutsu and Raku++
  • How much do they consider Rakudo's behavior authoritative, in the short term or the long term? How do they relate to unspecified behavior in Raku?
  • What was the primary motive to create these new runtimes?
  • How is string and regex performance looking, two historically crucial aspects of the Raku language?
• To all parties: does my ban extend to these new projects, and who has the authority to decide one way or another? Was there a discussion about the use of the raku.online domain by Andrew?
• To anybody who feels they might have an answer: how much impact does it have on the utility of the language/ecosystem to leave 6model and MoarVM in particular? How does this affect something like Red or OO::Actors?

That's it! I think this really became the chaotic article I expected it to be but perhaps the reason I was drawn to Raku is because I can also (only) work under these conditions. Exciting times ahead!