Perl 6 adopts the Raku name

Two source-incompatible languages had names that looked like consecutive versions of the same language. That is the problem Elizabeth Mattijsen raised in problem-solving issue 81 in August. On October 15, she confirmed on the users mailing list that the decision to rename Perl 6 to Raku had been made. She described the replacement of the old name as a gradual process with technical and emotional consequences.

The accepted Path to Raku plan gives that decision an implementation scope. This is a change to how the language identifies itself and how people find its tools. It is not an instruction to convert existing Perl 5 programs to a successor dialect.

My interest in Perl remains its direct expression of one-off text work. A separate language name is useful because it lets that preference stand on its own technical grounds. Choosing Raku should likewise be a decision about that language, without a number suggesting that an existing Perl program has simply fallen behind its next version.

The original version story no longer described the software

Mattijsen's issue explains that Perl 6 began as the intended next version of Perl. While it took time to reach an initial release, development of Perl 5 continued. The result was two sufficiently different languages that source compatibility did not follow their apparent numbering relationship.

That is a concrete problem for explanations of compatibility. A reader encountering a version number ordinarily expects some relationship between releases of one system. Here, the name required a correction before the discussion of actual language behavior could begin. The issue argues that this confusion harms both languages, while acknowledging that the bare Perl name is still associated with Perl 5.

The argument does not require treating shared history as a mistake. The languages can retain design influences and community relationships while carrying distinct names. What needs correction is the implied upgrade relationship. A separate name removes that implication from the first description a new reader sees.

The discussion also records disagreement over whether renaming can improve adoption. In an August comment, tadzik argues that a new name cannot replace visible use and useful software. That objection identifies a limit on the decision. Clarifying identity can remove confusion, but it does not establish that either language has solved every problem of popularity or ecosystem growth.

Governance required an implementation plan

Jonathan Worthington's August 12 response asks for more than agreement on a word. He places the issue under the language decision process and requires a pull request that reviewers can evaluate. The proposed change needs concrete steps for the period after approval.

His requirements include a description of the relationship to the Perl family and a plan for explaining redirects to visitors. Conference participation also needs consideration because people associated with both languages want to continue learning from each other. Those requirements connect the name to actual places where users encounter the project.

Worthington explicitly distinguishes the decision from the earlier use of Raku as an alias. In his account, that earlier situation lacked enough guidance about implementation. A name can be available without its use becoming consistent across documentation and tools. Requiring an actionable plan addresses that coordination problem.

The resulting pull request 89 was merged on October 14. Its accepted document says the transition cannot be complete in scope or time at the outset. That is a useful description of the work. Approval settles the direction while leaving a substantial amount of compatibility and infrastructure work to carry out.

A language name is different from a compiler name

The discussion preserves the distinction between the language and its implementation. Damian Conway's August contribution argues against using Rakudo as the new language name because it already identifies the principal compiler. The accepted plan retains that separation.

The plan proposes rakudo as the executable's implementation name, with raku and perl6 as symlinks. These are planned transition arrangements, not evidence that every distribution has already installed the same commands. A package's executable names remain a separate operational question while the rename proceeds.

Roast continues to specify the language. The plan changes the name of the language the tests specify, while preserving the distinction between specification and implementation. This matters because renaming the language should not imply that one compiler's current behavior has become the entire definition of the language.

NQP also keeps its name and the expansion Not Quite Perl. The plan does not pursue a universal deletion of the word Perl from every component. Its stated purpose permits historical and implementation names where they retain a useful meaning. A consistent public identity does not require pretending that the project's history has disappeared.

Compatibility constrains the technical transition

The accepted plan says existing scripts should continue to work without changes for the foreseeable future. That requirement shapes the proposed API transitions. For example, the .perl method is to gain a .raku replacement, with staged specification and deprecation rather than immediate removal.

The compatibility detail is significant. A default .raku method should check whether a type supplies a non-default .perl method and call it when necessary. Simply changing the name of a method in the core would not preserve the behavior of modules that implement the older method themselves. The fallback addresses that extension point.

The plan similarly proposes $*RAKU and the Raku class as replacements for $*PERL and the Perl class. They begin as aliases before becoming actual declarations at a language boundary. This is a staged change to exposed names, with the timing tied to language-version decisions.

RAKULIB is proposed as the replacement environment variable for PERL6LIB. If present, it should take precedence. That precedence rule matters because introducing two equivalent-looking configuration names without deciding which wins would create a new ambiguity during migration. The document makes the intended selection explicit.

These are decisions in an accepted transition plan. Reporting them as facilities already available in every installed compiler would mislead users. The document's module-author guidance specifically says not to rely immediately on the new methods and type names.

File extensions affect more than source archives

The plan selects .raku for scripts, .rakumod for modules and .rakudoc for documentation. It also addresses .rakutest and .t for tests. Those choices affect the tools that identify a file's language, not only the appearance of repository filenames.

The shared .t extension creates an explicit detection problem. Editors that understand shebangs or other heuristics should use them to distinguish tests written in different languages. Tools oriented specifically toward Raku can make a different assumption when a test lacks a shebang. The accepted document records that distinction instead of assuming every .t file belongs to one language.

Module compatibility makes an immediate bulk rename inappropriate under the plan. Its draft guide asks authors to retain .pm6 initially so modules continue to work with existing Rakudo installations. A future switch also needs matching changes in META6.json. Renaming files without updating the metadata that locates them would not complete the transition.

I find this compatibility detail more consequential than the choice of a shorter word. A clear identity helps a new user choose the right documentation. Existing users still need the installed compiler and module metadata to agree about where their code lives.

Discovery requires historical continuity

The plan calls for websites containing perl6 in their names to redirect permanently to their new equivalents. It also asks for an explanation when a visitor arrives through such a redirect. Reaching the correct page is necessary, but the visitor needs enough context to know that the redirect has not taken them to an unrelated project.

External references have the same problem. Old questions, books and discussion archives cannot all be rewritten at once. The plan asks for coordinated changes to site tags and an explanation of the rename so that searching for Perl 6 does not suddenly stop finding relevant material.

IRC logs provide a particularly concrete example. The document expects old logs to remain searchable under their former channel names because migrating them appears difficult. New channel identities and historical search locations can therefore coexist. That is an explicit preservation of access to past discussion while the current community adopts its new name.

The accepted document also leaves event organizers and local groups free to choose their scope. A distinct language name does not compel every shared meeting to split. It gives organizers a clearer way to say whether an event serves Perl, Raku or both.

For module authors, the immediate guidance concentrates on documentation and repository names while deferring code-level dependencies on the new identity. A renamed repository also needs its sources entry in META6.json updated. That small instruction captures a practical requirement of the transition. Public names can change first, but the references that tools use to retrieve the software still have to point to the right place.