The Lineage of Perl and Raku — Forty Years of One Language Becoming Two

From Perl 1.0 in 1987, through the Perl 6 that began in 2000, the first stable release that took fifteen years to arrive, and the 2019 rename to Raku. Twelve parts answering 'what happened to Perl 6' and 'is Raku Perl' with design decisions and primary sources. The conditions under which a name becomes technical debt, the decision to define a specification as a test suite, the bet on a general-purpose VM that did not pay off — this is also a textbook for anyone building a language.

perlrakulanguage-designhistoryprogramming-languagesyapc

The Answer, Up Front

This series runs to twelve parts, but the conclusion fits in three lines.

  • Raku is the new name for Perl 6. It was renamed in October 2019. Same language.
  • Perl 6 was never the next version of Perl 5. It was 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.

That is the answer. What this series is about is how those three lines came to be true.

Why Write This Now

In November 2026, YAPC::Tokyo 2026 takes place at Tokyo Big Sight. The theme is “Patchwork” — scraps of fabric stitched together, and Perl as the language that stitches disparate systems into one.

The story of Perl 6 and Raku meets that theme head-on. It is the story of an attempt to make one piece of cloth that ended up making two. And the outcome was neither failure nor success: both pieces are still in use.

There is a second reason of timing. In September 2026, Rakudo switches over to the compiler infrastructure it has been rebuilding for six years (RakuAST). A language that began more than twenty years ago is replacing its foundations right now. The final part of this series covers that.

The Questions This Series Is Trying to Answer

Most people carry roughly this impression of Perl 6 and Raku:

“Perl 6 never actually shipped, right?” “It shipped, but nobody uses it.” “They changed the name because it failed.”

None of these is true. But there are reasons people believe them, and those reasons are precisely the subject of this series.

Concretely, five questions:

  1. Why break compatibility? Why wasn’t an improved Perl 5 enough?
  2. Why did it take fifteen years? If not sloth or chaos, then what was so hard?
  3. Why change the name? What does it actually consist of, to rename something after nineteen years?
  4. What was Perl 5 doing all that time? Waiting? Or something else entirely?
  5. Where does it stand now? What is the accurate state of things in 2026?

The Twelve Parts

Part One — The Language Called Perl (1–2)

# Title Contents
1 Why Perl Was Born 18 December 1987. The gap between awk and C. A language built by a linguist
2 What Perl 5 and CPAN Built The 1994 rewrite. The invention of the package repository

Part Two — The Fifteen Years of Perl 6 (3–8)

# Title Contents
3 In 2000, Perl 6 Began A smashed mug. What happens when you crowdsource a language design: 361 RFCs
4 What It Set Out to Change Sigil invariance, grammars, multiple dispatch, rationals — each one a language’s worth of work
5 Four and a Half Years Without an Implementation, and One Year of Pugs A Perl 6 written in Haskell rewrote the relationship between spec and implementation
6 The Bet on a General-Purpose VM Why Parrot went unused. What MoarVM gave up in order to finish
7 Defining a Specification as a Test Suite Abandoning prose. “The specification is: it passes roast”
8 Christmas 25 December 2015. The first stable release, fifteen years after the announcement

Part Three — The Rename (9–10)

# Title Contents
9 When a Name Becomes Technical Debt Three parties all losing. On the unverified claim a name can carry
10 Path to Raku What you count when you rename something after nineteen years. Reading the migration plan

Part Four — Raku as a Language, and 2026 (11–12)

# Title Contents
11 Promoting Regular Expressions to a Language Feature Grammars. The thing Raku has that other languages don’t
12 Raku in 2026 RakuAST, 6.e, and how to write “small but ongoing” honestly

How This Series Is Written

Since the subject is forty years of other people’s work, the rules come first.

1. Never write “currently.” Write “as of September 2026.” This series is written expecting to go stale.

2. Never write “thriving” or “dead.” Both are judgements, not facts. The facts are that monthly releases have continued 196 times, that two implementations other than Rakudo appeared in 2026, and that the dedicated IDE has been discontinued. All three go on the page.

3. Don’t declare the rename a success or a failure. What it achieved and what it did not both get written down. Readers can do the evaluating.

4. Anecdotes stay anecdotes. There is a famous mug in this story, and the details vary by source. It gets written as “it is said that.”

5. Go to primary sources. The rename has a public GitHub issue and a public migration document. Each release has an announcement. Nothing here is written from second-hand quotation.

Who This Is For

  • People who have written Perl and don’t know where Perl 6 ended up — probably the largest group
  • People interested in language implementations — parts 5 through 7 and part 11 are for you
  • People building their own languages — Perl 6 is a rare case where the design decisions are all public

On that last point: I build a language myself. It has multiple backends, and it holds them together by using the interpreter as an oracle against which the others are diffed. At least three of the decisions in this series are ones I have actually faced. Part 6 (how many backends can you really maintain), part 7 (defining a spec as tests), and part 11 (how you let people write parsers).

This is a series about someone else’s history, but it is not written as someone else’s problem.


This series will be updated between September and November 2026.

← Back to The Lineage of Perl and Raku