Yes, it looks like the next release of Rakudo (2026.09, tentatively planned for 26 September) will be the first Rakudo release that will use the new Raku backend (based on a new grammar producing RakuAST) as the default when compiling a program written in the Raku Programming Language. Until then one had to specify the RAKUDO_RAKUAST=1 environment variable to activate the new backend.
It is a major step towards releasing the next Raku language level, tentatively still called "6.e" for historical reasons, later this year.
Note that the 2026.09 Rakudo release will not remove the old backend from the core just yet: you will be able to activate the old backend by specifying the RAKUDO_LEGACY=1 environment variable. However, the old backend will be removed when the 6.e Raku language level is released. So it is very important to check what these changes will mean for you!
Immediate effects
So what will a user of this Rakudo release notice with their apps and libraries?
Nothing
In the past weeks the Raku ecosystem has been thoroughly scoured for code that would stop functioning in RakuAST. Some finds turned out to be omissions / errors in the RakuAST implementation (which then have been fixed). Others turned out to be modules doing (semi-)naughty things, for which Pull Requests were made to ensure they will continue to operate in RakuAST.
Running slower
It could well be that your code is running without issues, but all of a sudden runs slower than before. Years of optimizing the old backend were mostly lost in RakuAST. And had to be re-created in the RakuAST-based backend. Which may have lost a few nooks and crannies that affect the execution speed of your code. Slower execution should be reported as a bug, so that it can be fixed!
Running faster
One of the goals of the RakuAST projects was to be able to provide better optmizations. Some of the ideas for these optimizations have already been implemented in RakuAST. And as a part of this work, a lot of aspects of the runtime have been held under scrutiny as well, resulting in some quite nice optimizations on the legacy backend as well. So it might well be that your code just runs faster. Win!
Not running
That could well be the case (although unlikely) if your code didn't live in the Raku ecosystem. There are a few experimental features that have been removed in RakuAST: if your code was using them, then the next release of Rakudo will break your code.
Macros
In the 6.e release of Raku, the macro statement will not be supported. Nobody was really happy with the experimental macro syntax or funcionality. It was felt that it would be best not to support a macro feature in 6.e at all. Because there are still many ideas floating around about how to implement macros.
Freeing up the macro keyword would also allow more experimentation in implementing macro-like functionalities in the Raku ecosystem once the 6.e language level is released.
Slangs
Raku slangs always effectively sub-classed the grammar of the Raku Programming Language. Since that grammar has changed (a lot) internally, unaltered slang code will most likely simply not work because it is not attaching to the right hooks in the new grammar. Finding the right hooks in the new Raku grammar is not something that can be done automatically or programmatically. But there are a whole lot of slangs in the ecosystem that can be checked for inspiration.
But more importantly, there's a module called Slangify that will at least simplify the way a slang can be activated (after having found the right hooks in the new Raku grammar).
Depending on some P5xxx modules
Some of the modules that were part of the CPAN Butterfly Plan were doing pretty naughty things to be able to provide the same semantics that Perl was providing.
Specifically the P5tie module (which attempted to mimic the functionality of tie from Perl) has been disabled. As long as the legacy backend is available, installing an earlier version will still work but only until Raku 6.e is released. Fortunately, Raku itself provides a much richer API to customizing behaviour of arrays and hashes, so a conversion of existing should be possible.
In practice it is not expected that there's much code out there depending on these modules, as the CPAN Butterfly hasn't really been a success.
Unknown errors
It could well be that the core team has missed some other migration issues. Such issues should be reported as quickly as possible, so that they can be fixed as quickly as possible!
Please Test!
If you have a code base that stays up to date on getting the most recent Rakudo implementation, you should test whether it works with RakuAST. If you are on the most recent 2026.08 release of Rakudo, you only need to add RAKUDO_RAKUAST=1 to the environment.
Conclusion
These are exciting times for the Raku core team.
The RakuAST project was started by Jonathan Worthington in 2020, with the help of a grant. Since then, many people have worked on the RakuAST project over the years, producing over 4400 commits! The people in question (in alphabetical order):
- Vadim Belman
- Brad Gilbert
- Daniel Green
- John Haltiwanger
- Nick Logan
- Elizabeth Mattijsen
- Stefan Seifert
- Jonathan Worthington
It's good to see it finally coming to an initial completion, and fruition! And a big thank you for all the people involved in getting this together!
Top comments (3)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
RakuAST reaching the default path is a significant compiler architecture milestone. The most interesting aspect is not simply replacing the backend, but creating a cleaner intermediate representation that can support future optimization passes without depending on legacy grammar internals.
For migration, I would treat 6.e compatibility as a compiler validation problem. CI should run the same test corpus against both RakuAST and legacy compilation, then compare AST behavior, generated code, runtime semantics, performance counters, and failure signatures. Benchmarking should include compilation time, memory consumption, startup latency, and representative workload throughput.
Slang authors especially need regression suites around grammar hooks because syntactic compatibility cannot be inferred from runtime tests alone. A compatibility matrix for modules would also make ecosystem migration considerably more predictable.
4400 plus commits over several years is impressive engineering persistence. This is exactly the kind of compiler transition where community testing can uncover edge cases the core team cannot realistically anticipate.
Thank you for your thoughts. Pull Requests are welcome! :-)
I am glad to hear that my reply was of some help.
I need your assistance with one specific thing; would you please contact me? I really need your help.t_g_@kanelim1997
Some comments have been hidden by the post's author - find out more