Christmas — The First Stable Release, Fifteen Years On, and Why a Release Is a Promise

The Joke That Never Named a Year

Perl 6 had a long-running joke.

“Perl 6 will be out by Christmas.”

The punchline is that it never says which year’s Christmas.

For fifteen years, the joke kept working. And a joke that keeps working means it had not shipped.

In February 2015, in his FOSDEM keynote, Larry Wall named the year. The talk was called “Get Ready to Party!” Perl 6 would ship production-ready at Christmas 2015.

At the development release that October, he put it this way:

As the old joke goes, Perl 6 is coming out this Christmas. Only this time, he meant it.

25 December 2015 — Perl 6.c “Christmas”

It shipped. Fifteen years and five months after the announcement.

What Was Released

This needs stating precisely. What was released was a frozen point of roast.

As part 7 covered, Perl 6’s specification lives in the roast test suite. “6.c” refers to roast, frozen as of December 2015.

The implementation — Rakudo — had been running before that. Rakudo Star had been distributed since 2010, and people were already writing Perl 6 in practice.

So what changed?

A Release Is a Promise, Not a Feature

This is the point of the instalment.

Almost no technical capability was added by the 6.c release. What was added was a promise.

From here on, behaviour that passes 6.c’s roast will not be broken.

That is what a stable release means.

• Before: the specification moves. Code you write today may stop working next month
• After: code that declares 6.c will run on future Rakudos

The version pragma use v6.c; from part 4 is the implementation of that promise. One compiler supports several language versions simultaneously.

Here is this series’ ninth pattern.

A release is not the addition of features; it is the beginning of a commitment not to change.

Which is why “they should have waited until more was ready” misses. The later the promise starts, the longer the period with no promise at all.

And conversely: the moment the promise starts, the weight of backward compatibility starts. What part 2 said about Perl 5 began to apply to Perl 6.

What Were Those Fifteen Years?

This is a good place to add up the first half of this series — the four reasons I flagged in part 3.

1. The design was too ambitious (part 4)

Sigil invariance, grammars, multiple dispatch, meta-operators, junctions, laziness, gradual typing, a MOP, a rational numeric tower. Any one of them is a language’s worth of work, and they were not independent.

2. The bet on an implementation substrate failed (part 6)

Years invested in Parrot, ultimately unused. The premise of a general-purpose VM — that many languages would arrive — did not hold. The move to MoarVM happened in 2013, and 6.c landed two and a half years later. In other words: once the substrate was settled, it went fast.

3. The specification kept moving (parts 5 and 7)

A long back-and-forth in which implementation catches up and the spec shifts. The mechanism itself is healthy — Pugs started it. But when that oscillation reaches the VM layer, the cost changes by an order of magnitude.

4. There were few full-time hands

Pugs slowing down is the sharpest example. One person’s departure changed the whole pace.

Summed Up

Not sloth, not chaos. Scope, one failed substrate bet, and thin staffing.

And of those four, only the second was something that could be redone. MoarVM in 2013; 6.c in 2015. You could say the two and a half years after the substrate was settled were this language’s real completion period.

What Was Gained, and What Was Lost

Shipping is an achievement in itself. In fifteen years, what they set out to do largely got done. The nine items from part 4 exist as a working language.

But things were lost in those fifteen years. Worth writing honestly.

Lost 1 — Reputation

“Perl 6 is slow” was mostly a verdict on the Parrot era (part 6). The substrate was replaced; the reputation outlived the substrate.

Lost 2 — The People Who Were Waiting

Those who heard “a few years” in 2000 moved to other languages during the fifteen. Ruby on Rails arrived, Python grew in scientific computing, JavaScript came to the server, Go and Rust appeared.

When Perl 6 shipped, most of the people who had been waiting were no longer waiting.

Lost 3 — The Relationship With Perl 5

This is the heaviest one.

Perl 5 did not spend fifteen years waiting (parts 2 and 4). Moose arrived, 5.10 arrived, annual releases began; it evolved on its own.

And from the outside, the odd state of “6 exists and you’re still on 5” persisted for fifteen years. Perl 5 users were harried by a successor that did not exist.

The party that lost most in those fifteen years may not have been Perl 6 but Perl 5.

6.d “Diwali” (2018)

The second language version arrived in 2018, named Diwali — the Hindu festival of lights.

Christmas, then Diwali: the version names deliberately cross cultures. As of September 2026, 6.d is the default and 6.e is being drafted (part 12).

And the Name Problem Remained

With 6.c out, Perl 6 stopped being an unfinished language. The technical question had an answer.

But nothing about the name problem was solved.

• Perl 5 was still seen as “still on 5 when 6 exists”
• Perl 6 was still introduced as “the new version of Perl”
• Perl 5 still could not advance its version number

And importantly, shipping 6.c is what made a rename possible.

Changing the name while unfinished reads as fleeing a failure. A finished language changing its name is a declaration of independence.

Part of the reason the rename happened in 2019 is right here.

---

Next (part 9): When a name becomes technical debt. For nineteen years, the name “Perl 6” carried an unverified claim. The structure in which all three parties lose, and the conditions under which a name becomes debt.