Raku in 2026 — A Language Started Twenty Years Ago Is Replacing Its Foundations

The facts in this article were verified as of 18 September 2026. The final part deals with the present, so it goes stale fastest. Check versions, schedules and status at rakudo.org and Rakudo Weekly News. This note is itself part of the instalment’s subject.

Mid-Replacement of the Foundations

The biggest event in Raku in 2026 is not a feature. It is the replacement of the compiler’s foundations.

It is called RakuAST.

It is a rebuild of Rakudo’s compiler from parsing through to code generation, with a new grammar and a layer that represents a Raku program as an explicit AST.

Previously, Rakudo assembled the compiler’s intermediate representation directly during parsing. RakuAST inserts a stage in between.

⚠️ The terminology wobbles. Official announcements sometimes say “new backend,” but functionally this is a rebuild of the compiler’s frontend. When writing about it, “the new compiler infrastructure” — naming the role — is safer.

Why It Was Built

Jonathan Worthington began it in 2020, as a grant project supported by The Perl Foundation.

That name appeared in parts 6 and 11: the person who built 6model, MoarVM, and Cro. A large fraction of Raku’s technical foundation can be explained by this one person’s work.

The motivations were:

• The intermediate representation was implicit, so there was nowhere to put optimisations
• The syntax tree was not manipulable as objects, so macros and syntactic introspection could not be implemented
• The compiler’s structure was hard to understand, which was a barrier to contribution

In other words, before making it faster, this was construction work to make it workable on.

Here is one of the things I most wanted to say across this series.

Sometimes, before you can add optimisations, you have to build the place where optimisations go.

And that work took six years. Six years whose goal is that the output behaves the same as before. It is the same kind of time as the “fifteen years” of part 8: progress that is hard to see from outside.

The 2026 Schedule

When	What
2026.09 (scheduled 26 September)	RakuAST becomes the default. The old infrastructure remains via RAKUDO_LEGACY=1
At the 6.e release (expected within 2026)	The old infrastructure is removed entirely

The staging should look familiar. It is the same pattern as Path-to-Raku.md in part 10.

Switch the default → keep the old behind an environment variable → remove at a version boundary.

The experience of losing fifteen years to breaking compatibility survives in this community as a discipline for breaking changes.

What Changes, and What Does Not

Does not change — the language specification as users see it. Existing code running unchanged is the goal, and extensive testing against the module ecosystem has been carried out.

Does change — slangs (grammar extensions) need updating. As part 11 described, Raku lets users extend the grammar. Because the grammar’s structure changes, extensions that relied on the old one will not just work.

A language that decides to open its grammar pays twice when it changes that grammar. The price named at the end of part 11 is now actually being charged.

About Macros — Easy to Get Wrong

RakuAST is the foundation on which macros can be implemented. But macros are not in 6.e (per the outlook as of September 2026).

Writing “RakuAST is coming, so macros are available” is simply wrong. Accurately: the ground on which macros can be implemented now exists. Macros themselves are still ahead.

Describing Raku in 2026, Accurately

Rule 2 of this series’ writing rules said:

Never write “thriving” or “dead.” Both are judgements, not facts.

So what are the facts? Here they are.

Item	Status as of September 2026
Language version	6.d is the default. 6.e expected within the year, not yet released
Compiler	Rakudo. 2026.08 is Release #196
Compiler infrastructure	RakuAST becomes default in 2026.09
VM	MoarVM, effectively the only one
Number of implementations	3. Alongside Rakudo, mutsu (Rust) and Raku++ (C++17) appeared in 2026
Governance	Raku Steering Council
Ecosystem	zef (fez / rea), raku.land. Small, but ongoing
Dedicated IDE	Comma is discontinued
Perl (5.x)	5.44 (2026-07-15). Perl 7 unreleased

Five lines summarise what that table says. They are this series’ answer.

1. Monthly releases have continued 196 times. The strongest evidence of continuity
2. A six-year rebuild of the compiler infrastructure is nearing completion. This is advance, not maintenance
3. The scale is small. The dedicated IDE is gone, and there are few modules
4. The language specification is heading for its next version. It has not stopped
5. For the first time in a decade, implementations other than Rakudo are running. The next section covers this

Writing those five lines together is the accurate description of Raku in 2026. Quote any one of them alone and you can make it read as thriving or as finished. So put them together.

For the First Time in a Decade, Implementations Other Than Rakudo Are Running

I learned this while writing this series, so let me write it in the order it happened. Part 7 spoke of “the loss of the second implementation.” Two had appeared right after.

Implementation	Author	Language	Approach	Started
mutsu	tokuhirom	Rust	Bytecode VM	2026-02
Raku++ (rakupp)	ash	C++17, no third-party deps	Hand-written lexer and parser, tree-walking evaluator	2026-07

Neither is a fork of Rakudo; both are written from scratch. And both chose Artistic-2.0 — the same licence family as Perl and Raku.

Conformance is measured with roast

	Roast files fully passing (of 1,464)	Individual tests
mutsu	1,433 (97.9%)	—
Raku++	676 (46%)	200,843 / ~219,610 (91%)

That this table can exist at all is a consequence of part 7’s subject.

“Conforms to Raku” is a number rather than a claim because the specification was moved from prose into a test suite. Had the spec stayed as the Synopses, these two projects would have had to self-report how much Raku they were.

They measure the ecosystem honestly too

Both know that passing roast is not enough, and separately measure whether real modules work.

• mutsu: of 1,624 distributions, 41.2% pass every test file that rakudo passes
• Raku++: 1,006 of 2,529 pass their own test suites. But running Rakudo on the same machine says only 1,791 are reachable there at all (the other 738 fail for want of libgsl, fontconfig or a network). So 1,006 is 56% of what is actually reachable.

They measure the denominator before quoting a ratio. That is the right discipline with numbers.

The pace of development

mutsu began in February 2026 and reached 12,266 commits and over 8,700 PRs in seven and a half months — roughly 55 commits a day.

Its branch names read claude/raku-line-profiler-design-…, so this is heavily AI-assisted development. It is not sloppy, though. Recent commits include:

docs(adr): record ADR-0106's gates as measured after Slice 2
docs(adr): record the three corrections ADR-0106 Slice 2 forced

Design recorded as ADRs, work cut into slices, gates recorded as measured, and “the corrections the implementation forced” kept as documents.

Part 5 said:

Implementation produces a different kind of error than reading does.

mutsu keeps those corrections rather than discarding them. The shape resembles Pugs starting roast.

Grammars are trying to travel, for the first time

Raku++ makes this its pitch:

A Raku grammar stays a .raku file and any host language drives it — which is something none of them has an equivalent of

It exposes one C API, with bindings for C++, Go, JavaScript, Python, Rust and Wolfram. That is, it aims at “using only Raku’s grammars from another language.”

The closing of this instalment says grammars have not spread in Raku’s own shape. The attempt to spread them has only just begun.

Honest caveats

• Neither is production ready, as both state outright
• mutsu’s known gaps: undeclared variables are not rejected at compile time, exception types are limited, the package manager is young, RakuAST is unimplemented
• The numbers move daily. mutsu’s README says compatibility improves every day

⚠️ Every figure here was checked in the respective repositories on 18 September 2026. Re-measure before quoting — rule 1 of this series.

What this does to the argument

Part 7’s worry is partly resolved.

With a single implementation, an implementation bug can settle in as “the language’s specification.” With three, a disagreement becomes visible as either a hole in the spec or a bug in an implementation.

And part 6’s pattern applies here:

One user cannot reveal a fake generalisation.

For over a decade, roast had exactly one user: Rakudo. How much of the specification roast actually captures is about to be tested.

So What Is Raku Good For?

“Small but ongoing” describes a state; it is not a reason to use something. Here is what reason there might be to choose Raku in 2026, measured rather than asserted.

All numbers below were measured on 18 September 2026, macOS / Rakudo Star 2026.08, with the reproduction commands alongside. Numbers go stale — measure them again yourself before quoting them.

One Decision Runs Underneath

Raku’s strengths are less individual features than one decision expressed many times.

Pay in performance and in scale so that the obvious way to write it gives the right answer.

Most languages chose the opposite: make the cheap answer the default, and let people fetch the correct one when they need it. Raku made the correct answer the default.

Measurement 1 — Strings

Input was constructed explicitly in decomposed form (e + U+0308) in every language.

raku    -e 'my $s = "noe\c[COMBINING DIAERESIS]l"; say $s.chars, " / ", $s.flip'
python3 -c 's = "noe\u0308l"; print(len(s), "/", s[::-1])'
perl -CS -e 'my $s = "noe\x{0308}l"; print length($s), " / ", scalar reverse($s), "\n"'

Language	Length	Reversed	👨‍👩‍👧‍👦 length
Raku	4	lëon	1
Swift	4	lëon	1
Python 3	5	l̈eon ← the diaeresis moved onto l	7
Perl 5	5	l̈eon ← same	7

Reversing a string moves a diacritic onto a different letter. That is the default behaviour of a code-point-based language.

But this is not Raku’s alone. Swift is grapheme-cluster based too. What differs is that in Raku it carries straight into regexes and grammars (part 11).

Measurement 2 — Numbers

raku    -e 'say 0.1 + 0.2 == 0.3; say (0.1 + 0.2).WHAT, " ", (0.1 + 0.2).nude'
python3 -c 'print(0.1 + 0.2 == 0.3, 0.1 + 0.2)'

Language	0.1 + 0.2 == 0.3	Actual value
Raku	True	Rat 3/10, exactly
Python 3	False	0.30000000000000004

Decimal literals are rationals by default. Many languages have a Fraction or Rational; almost none make it what a literal means.

Four Areas Where It Is Clearly Strong

Area	Why	Versus the alternatives
Parsers / DSLs / bespoke format readers	Grammars are a language feature (part 11)	ANTLR / yacc need a build step. Parsec / nom are host-language functions
Complex Unicode text processing	Graphemes, and they carry into regexes	Swift has graphemes but different regex expressiveness. Others manage normalisation by hand
Numeric work where exactness beats speed	Rationals by default, arbitrary-precision integers	Has to be asked for explicitly
Concurrency merging many event sources	react / whenever are syntax	Go’s select is channels only. RxJS is a library

What these four share is that they are areas where the correct answer is expensive. Raku is strong there because it made the expensive one the default.

The Honest Weakness

Measured in the same environment.

for i in 1 2 3 4 5; do raku -e 'say 1' >/dev/null; done   # average of five

Language	Startup (mean of 5)
Raku	138.8 ms
Python 3	38.4 ms
Perl 5	13.9 ms

Ten times Perl. That is a real disadvantage for one-liners and shell-script replacements, and relatively unimportant for long-running processes. It is a property of the implementation, not the specification — MoarVM startup plus loading the built-in library.

Plus what this instalment’s table already said: a discontinued IDE, and a module count not comparable to CPAN or RubyGems. (The implementation count is corrected in the next section.)

Summing Up

There are few situations where “you should use Raku” is the right advice. Recommending it for a new project in 2026 is hard on ecosystem and hiring grounds.

What can be said is this:

If writing a parser, handling complex Unicode, or numeric exactness is at the centre of the job, Raku is a clearly more comfortable option than the alternatives.

And one more value, which is not practical at all. As a showcase of language design, it is in a class of its own. Types, a MOP, concurrency, syntax extension and a numeric tower all live in one language, and every design decision is public. That is why this series had twelve parts to write.

Back to the Five Questions

The overview posed five questions. Time to answer them.

1. Why break compatibility?

Perl 5’s fundamental constraints — sigil rules, bless-based OO, arguments through @_ — could not be changed, because of backward compatibility. And backward compatibility weighed what it did because CPAN existed (part 2).

A successful language gets fixed in the shape of its success.

We want to change it. We cannot. Therefore we must build a different language.

2. Why did it take fifteen years?

Four reasons (totalled in part 8): the design was too ambitious (part 4); the implementation-substrate bet failed (part 6); the specification kept moving (parts 5 and 7); there were few full-time hands.

Not sloth, not chaos. And after the move to MoarVM, it shipped in two and a half years.

3. Why change the name?

Because “Perl 6” carried an unverified claim for nineteen years (part 9).

All three parties lost. Perl 5 looked finished, Perl 6 looked unfinished, and Perl 5 could not advance its version number.

And because it was completed in 2015, it could be renamed in 2019.

4. What was Perl 5 doing?

Not waiting. Moose arrived, 5.10 arrived, annual releases began, signatures stabilised, class landed. Perl 5.44 shipped in July 2026.

The party that lost most in those fifteen years may have been Perl 5, not Perl 6 — harried for fifteen years by a successor that did not exist.

5. Where does it stand now?

As in the four lines above. Small, but ongoing, and advancing.

The Thirteen Patterns From This Series

If you read this series as a technical text, I think this is what remains. None of it is specific to Perl or Raku.

#	Pattern	Part
1	A language’s fundamental constraints cannot be resolved by adding features; you rebuild the implementation	1
2	A successful language gets fixed in the shape of its success; larger assets mean higher cost of change	2
3	What a call for proposals returns is not a solution but a problem statement	3
4	Raise what gets added from features to rules	4
5	Implementation produces a different kind of error than reading does	5
6	One user cannot reveal a fake generalisation	6
7	Having N backends and having N verified backends are different things	6
8	Prose speaks vaguely about everything; tests speak precisely about some things	7
9	A release is not the addition of features; it is the beginning of a commitment not to change	8
10	A name freezes the claim made at the moment of naming	9
11	A rename is the work of counting every place the name is embedded	10
12	The length of a notation is an allocation against frequency	11
13	How easy syntax extension is trades against how small the base syntax is	11

And one more, which writing this instalment is what taught me.

Writing about the present means writing down when you checked.

This article opens with “verified as of 18 September 2026.” I wrote that not so much because it is honest as because without it the article is unusable.

An article that says “the latest version of Raku is…” cannot be judged without a date. Is it old? Is it current? There is no way to tell. A “present” with no date is not information to the reader.

The forty years this series covered are a vast example of exactly that. An article written in 2000 saying “Perl 6 will be out in a few years” was correct when it was written. The same structure as what part 9 said about names.

A name freezes the claim made at the moment of naming.

So does an article. Which is why you write the date.

Closing — Back to the First Three Lines

This series began with a three-line conclusion.

• Raku is the new name for Perl 6. Renamed in October 2019. Same language.
• Perl 6 was never the next version of Perl 5. Designed as an incompatible language, and it grew into one.
• Perl 5 is still alive. Perl 5.44 shipped in July 2026. It did not end.

Twelve parts later, those three lines are unchanged. What changed is that you now know why they are true.

And one last thing worth adding as fact.

In November 2026, in Tokyo, Larry Wall and Matz speak in the same room — the person who made Perl and the person who made Ruby.

The forty years in this series are a record of what Perl tried, what it gave up, and what it did not give up. Much of what it tried flowed out into other languages. CPAN became the ancestor of every package repository, its regular expressions became the industry standard, Moose’s object model flowed back into Perl 5 — and grammars — in Raku’s particular shape, have not spread.

Other languages can extend their syntax (part 11 laid them out by tier), and Racket is stronger than Raku in that tier. But a grammar you write as a continuation of regular expressions and inherit as a class still exists only in Raku.

What only Raku has is still only in Raku. That is where things stand in 2026.

---

Thank you for reading to the end. Corrections and updates are welcome.