Perl と Raku の系譜 — 1 つの言語が 2 つになるまでの 40 年

先に答えを書いておく

この連載は 12 話あるが、結論は 3 行で終わる。

• Raku は Perl 6 の新しい名前である。 2019 年 10 月に改名した。同じ言語だ。
• Perl 6 は Perl 5 の次のバージョンではなかった。 互換性のない別言語として設計され、そう育った。
• Perl（5 系）は今も現役である。 2026 年 7 月に Perl 5.44 が出ている。終わっていない。

ここまでが答えだ。この連載が扱うのは、その 3 行がどうしてそうなったかである。

なぜ今これを書くのか

2026 年 11 月、東京ビッグサイトで YAPC::Tokyo 2026 が開かれる。テーマは “Patchwork”。 布の切れ端を縫い合わせるように、異なるシステムをつなぐ言語としての Perl、という含意がある。

Perl 6 と Raku の物語は、このテーマと正面から噛み合う。 1 枚の布に戻そうとして、2 枚の別の布になった話だからだ。 そしてその結果は、失敗でも成功でもなく、2 枚とも今も使われているという形に落ち着いた。

もう 1 つ、時期の理由がある。2026 年 9 月、Rakudo は 6 年がかりで進めてきた コンパイラ基盤の刷新（RakuAST）を既定に切り替える。 20 年以上前に始まった言語が、今まさに土台を入れ替えている。 この連載の最終話はその現場を扱う。

この連載が答えようとしている問い

Perl 6 / Raku について、多くの人が持っている印象はだいたいこうだ。

「Perl 6 って、結局出なかったんでしょ」 「出たけど誰も使ってないやつ」 「名前を変えたのは失敗したからでしょ」

どれも事実に反する。 しかし、なぜそう思われているかには理由がある。 その理由こそが、この連載の主題だ。

具体的には、次の 5 つの問いに答えていく。

1. なぜ互換性を切ったのか。 Perl 5 の改良版ではいけなかったのか
2. なぜ 15 年かかったのか。 怠慢や混乱ではないとしたら、何がそんなに難しかったのか
3. なぜ名前を変えたのか。 19 年使った名前を変えるとは、具体的に何をすることなのか
4. Perl 5 は何をしていたのか。 待っていたのか、それとも別のことをしていたのか
5. 今どうなっているのか。 2026 年時点の正確な現在地はどこか

全 12 話

第 1 部 — Perl という言語（第 1〜2 話）

話	題	内容
1	Perl はなぜ生まれたか	1987 年 12 月 18 日。awk と C の隙間。言語学者が作った言語
2	Perl 5 と CPAN が作ったもの	1994 年の全面書き直し。パッケージリポジトリという発明

第 2 部 — Perl 6 の 15 年（第 3〜8 話）

話	題	内容
3	2000 年、Perl 6 が始まった	割れたマグカップ。言語設計を公募したら 361 本集まった
4	何を変えようとしたのか	シジル不変性、grammar、多重ディスパッチ、有理数。どれも言語 1 つ分の仕事だった
5	実装が無かった 4 年半と、Pugs の 1 年	Haskell で書かれた Perl 6 が、仕様と実装の関係を作り替えた
6	汎用 VM という賭け	Parrot はなぜ使われなかったのか。MoarVM は何を捨てて完成したのか
7	仕様をテストスイートで定義する	散文の仕様を捨てた決断。「仕様とは roast を通ることである」
8	Christmas	2015 年 12 月 25 日。発表から 15 年後の最初の安定版

第 3 部 — 改名（第 9〜10 話）

話	題	内容
9	名前が技術的負債になるとき	三方が損をしていた。名前が含む「検証されていない主張」の話
10	Path to Raku	19 年使った名前を変えるとき、何を数えるか。移行計画書を読む

第 4 部 — 言語としての Raku と、2026 年（第 11〜12 話）

話	題	内容
11	正規表現を言語機能に昇格させる	grammar。Raku で最も「他の言語に無いもの」
12	2026 年の Raku	RakuAST、6.e、そして「小さいが継続している」をどう書くか

この連載の書き方について

扱うのが他人の 40 年なので、書き方の規則を先に決めておく。

1. 「現在」と書かない。 「2026 年 9 月時点で」と書く。この連載は腐る前提で書く。

2. 「盛り上がっている」とも「終わっている」とも書かない。 どちらも評価であって事実ではない。事実は「月次リリースが 196 回続いている」であり、 「2026 年に Rakudo 以外の実装が 2 つ現れた」であり、 「専用 IDE は開発が終了した」である。並べて書く。

3. 改名を「成功」「失敗」と断定しない。 達成されたことと、達成されなかったことを両方書く。評価は読む人がすればいい。

4. 逸話は逸話として書く。 この連載には有名なマグカップの話が出てくるが、細部は資料によって異なる。 「〜と伝えられる」で書く。

5. 一次資料に当たる。 改名については GitHub の issue と移行計画書が公開されている。 版については各リリースのアナウンスがある。孫引きで書かない。

想定している読者

• Perl を書いたことがあり、Perl 6 の現在地を知らない人 — おそらく最大の層
• 言語処理系そのものに興味がある人 — 第 5〜7 話と第 11 話がそこ向け
• 自分で言語を作っている人 — Perl 6 は言語設計の判断が全部公開されている稀な事例だ

3 番目について 1 つ書いておくと、私自身が自作言語を作っている。 複数のバックエンドを持ち、インタプリタをオラクルにして他のバックエンドを縛る、 という構造で動かしている。この連載で扱う判断のうち少なくとも 3 つは、 私が実際に直面したものと同じだった。 第 6 話（バックエンドは何本まで維持できるか）、 第 7 話（仕様をテストで定義する）、第 11 話（パーサをどう書かせるか）がそれにあたる。

他人の歴史を語る連載だが、まったくの他人事としては書かない。

---

この連載は 2026 年 9 月から 11 月にかけて更新します。