Goose とは

Goose は、ヒープアロケータ ・ ガベージコレクタ (GC) ・ ライフタイム注釈のない、メモリ安全なシステム言語。構文は C と Rust に近い。コンパイラはプログラム全体を 1 つの C ファイルへ出力する。

動的な値 (伸び縮みする配列・文字列) は、すべて「データスタック」に直接置く。伸びるときはポインタを進めるだけで、スコープを抜けると 1 回の書き込みで解放する。この方式が、速さと省メモリの源になっている。

この資料の事実の出所

新しい言語で第三者の評価がまだ少ない。そのため、各主張が何に基づくかを区別して読む。

出自と現状

設計は Wouter van Oortmerssen 氏 (ゲーム開発会社を率い、自作言語 Lobster の作者でもある)。実装・ベンチマーク・サンプル・文書は、主に AI の Claude Fable が書いた。README が自らそう明記している。

ヒープのないメモリモデルと安全性

Goose のプログラムが持つメモリは 3 種類だけ。ネイティブのコールスタック、静的データ、N 本のデータスタック (N はコンパイラが決める)。これ以外のメモリは存在しない。

解放は 1 回の書き込み

データスタックは大きなアドレス空間を予約し (既定 2 GB。--stack-reserve で変更可)、使った分だけ確保 (commit) する。伸長はバンプポインタを進めるだけ。スコープを抜けると、ポインタを戻す 1 回の書き込みで、入れ子の深さや要素数に関係なく解放が終わる。実行時に追跡するのはバンプポインタだけで、残りはコンパイル時に証明する。

for round in 3 {
    var scratch: u8[>..] = [];                        // 伸長のみの配列: 伸ばすのはポインタを進めるだけ
    for i in 100000 { scratch.push((i % 256) as! u8); }
    print("round ", round, ": ", scratch.len, " bytes");
}                                                     // 解放: スタックトップへの 1 回の書き込み

出典は公式 README。このコード片そのものは未実行 (動作の確認は第 9 章のサンプルによる)。

参照は動かず、伸びても無効にならない

1 本のスタックに伸縮できる値は 1 つしか載らず、常に最上部にある。そのため伸長しても既存の要素は移動しない。README は「参照は伸長のあとも有効」を、性能の利点の 1 つに挙げる。push は新しい要素への参照を返すので、構築しながら要素同士をつなげられる。

struct Item { id: i32, weight: f32 }

var items: Item[>..] = [];
let first .= items.push(Item { 1, 0.5 });             // 要素 0 への参照
for i: i32 in 2..1000001 { items.push(Item { i, 0.0 }); }
first.weight = 99.5;                                  // 100 万回 push したあとも有効

注釈なしで、参照の寿命を守らせる

すべての参照とスライスには静的な「ルート」(その指す先の寿命を決める変数) がある。参照は、ルートの所有者より長生きできない。コンパイラがルートを推論し、関数をルートごとに特殊化するので、ライフタイム注釈は要らない。エイリアスや排他性の規則もなく、unsafe もない。違反はコンパイル時に、ルートと代入先を示して拒否される。

fn longest(a: u8[:], b: u8[:]) -> u8[:] { if a.len >= b.len { a } else { b } }

var outer: u8[>..] = [];
var w = outer[..];
{
    var inner: u8[>..] = [];
    format(inner, "inner text");
    w = longest(outer, inner);     // エラー: inner をルートとする参照を、より長生きする w へ格納

スライス T[:] は、どの種類の配列からも要素をコピーせずに範囲を受け取る。split は入力へのスライスを返し、u8[:] をキーにした辞書は文字列のコピーではなくビューを保持する。

データの置き方

Goose には「配列型」が 1 つだけあるのではなく、サイズの変わり方だけが違う配列型の一族がある。どれも [メタデータ][要素…] の形で、インラインに詰めて置く。要素の外側に別ブロックへのポインタを持たない。

文字列は u8 の配列

文字列専用の型はなく、u8 の配列で表す。使い分けは配列の種類で決まる。

• u8[>..]: 組み立て中の文字列 (ビルダー)
• u8[]: 完成した文字列。それを持つ構造体や配列の中にインラインで置く
• u8[..16]: 構造体の中に収まる小さな文字列
• u8[:]: 文字列のビュー

入れ子のデータが 1 つの連続ブロックになる

構造体が可変サイズの部分を含むと、それらは宣言順にインラインで並ぶ。注文 1 件は「バイト列」であり、中にポインタがない。

struct Item  { sku: u8[varint], qty: varint, cents: varint }
struct Order { id: varint, customer: u8[varint], items: Item[varint] }

var book: Order[>..] = [];
book.push(Order { id: 1001, customer: "alice",
                  items: [Item { sku: "SKU-441", qty: 2, cents: 1999 },
                          Item { sku: "SKU-7", qty: 1, cents: 500 }] });

enum は 2 つの大きさで持てる

代数的データ型 (ADT) は動的な多態の唯一の形で、継承も vtable もない。同じ ADT を、使う場所で 2 通りに格納できる。

• 固定モード (Shape): タグと、最大のバリアントの分だけの領域を持つ。添字で引け、上書きもできる
• 可変モード (Shape..): 各値がそのバリアントの実サイズだけを占める。配列は逐次的になり、値のバリアントは変えられないが、ペイロードの中への参照を取れる

enum Shape { Circle { r: f64 }, Rect { w: f64, h: f64 }, Dot }

var packed: Shape..[>..] = [];                 // 9・17・1 バイト (17 バイト × 3 ではない)
packed.push(Shape.Circle { r: 1.0 });
packed.push(Shape.Rect { w: 2.0, h: 3.0 });
packed.push(Shape.Dot);

バリアントごとに関数を定義する「ケース関数」で、タグに応じた呼び分け (ジャンプテーブル) も書ける。コンパイラが全バリアントを網羅しているかを検査する。

ポインタより狭いリンク (相対参照)

通常の参照 T& は 8 バイトの機械アドレス。相対参照は同じリンクを 1・2・4 バイトのオフセットで持つ。T&<u32> は、フィールド自身から同じ配列内の対象までの距離で、配列全体が位置に依存しない。オフセット 0 を null として使えるのは T&<u32>?。

struct Node { key: i32, left: Node&<u32>?, right: Node&<u32>? }   // リンク込みで 12 バイト

var image: u8[>..] = tree.to_bytes();           // 配列全体のバイト列
var loaded, ok = from_bytes<Node[>..]>(image);  // 検証してから値になる

from_bytes は、枠・タグ・長さ・リンクをすべて検査してから値にする。壊れた、あるいは悪意のあるファイルは、不正な参照ではなく false を返す。保存はバイト列を書くだけ、読み込みは読んで検証するだけで、シリアライザもスキーマもポインタの付け替えも要らないというのが README の主張。

言語機能 (エラー・ジェネリクス・スレッド・C)

エラーを何段上へでも返す: return E from f

return E from f は、関数 f の最も内側の有効な呼び出しの結果として E を返す。途中の関数は通常のシグネチャのまま。静的に検査され、parse_user の呼び出しはすべて load の呼び出しの内側になければならない。実装は、各フレームで検査する隠しの判別値で、アンワインダは使わない。

fn load(text: u8[:]) -> User[>..], u8[] {
    var users: User[>..] = [];
    each_split(text, '\n') { users.push(parse_user(it)); };
    return users, "";
}

fn parse_user(line: u8[:]) -> User {              // User を返す: Result もエラー引数もない
    let comma = find(line, ",");
    guard comma >= 0 else { return [], str("expected name,age: ", line) from load; }
    ...
}

ジェネリクスと、消えるブロック

型を書かないパラメータは、そのままジェネリクスになる。関数値はコンパイル時の存在で、クロージャオブジェクトも関数ポインタもない。そのため、高階関数は手書きのループと同じコードに展開される。ブロックの中の return は、そのブロックを囲む関数から返る。

fn twice(x) { x + x }                              // 型なしのパラメータはジェネリック

fn each_pair<T, F>(xs: T[:]) {                     // F は関数値 (コンパイル時の実体)
    for i in 0..xs.len - 1 { F(xs[i], xs[i + 1]); }
}

let evens = xs.filter() { it % 2 == 0 };           // 結果は evens へ直接構築 (一時領域なし)
let total = fold(xs, 0) { acc, x => acc + x };

すべて単相化される。結果を返すときも、呼び出し側の変数へ直接構築する「その場構築」が保証される。words.push(str("word", i)) は、整形した文字列を新しい要素へ直接書き込む。

共有メモリのないスレッド

thread_fn とそこから呼ばれるものは、独立したプログラムとしてコンパイルされ、自分のデータスタックとグローバルのコピーを持つ。値は型ごとのキューで渡し、参照を含まない「平坦な」値に限る。平坦な値は連続しているので、渡すのは 1 回の memcpy。データ競合・ロック・アトミック・メモリオーダリングは、言語に存在しない。

thread_fn worker() {                                // 独立したプログラム。自分のメモリを持つ
    loop {
        let job = qget<Job>();                      // Job の型付きキューで待つ
        guard job.n >= 0 else { break; }            // -1 は停止の合図
        qput(Result { n: job.n, digits: count_digits(job.n) });
    }
}
for i in n { ids.push(thread_spawn(worker)); }

worker は thread_spawn_contained で起動すると、失敗した検査や abort がその worker だけを終わらせる。メッセージは標準エラーではなく、待っている側へ届くので、監督役がログに残して作り直せる。

C との連携

extern fn が、Goose のシグネチャを C のシンボルに結びつける。スライスは { data, len } として渡り、構造体はポインタ経由で埋められる。math と os のモジュールがこの仕組みを使う。C 側から Goose を呼ぶ手順も、チュートリアルにある (第 19 節。当資料では未確認)。

extern fn hypot(x: f64, y: f64) -> f64;             // libm からそのまま
extern fn crc32_bytes(s: const u8[:]) -> u32;       // スライスは { data, len } で渡る

このページのコード片は、いずれも公式 README からの引用で、そのものは未実行 (動作の確認は第 9 章のサンプルによる)。

実行の仕組みと使い方

コンパイラは、プログラム全体を 1 つの C ファイルへ出力する。その C を、同梱の TinyCC でコンパイラ自身のプロセス内で実行するか (ビルド手順なし)、システムの C コンパイラでネイティブの実行ファイルにする。

主なコマンド

導入の前提

• 配布物の中身: コンパイラ・標準ライブラリ・TinyCC のランタイム・パッケージ (gfx ・ audio ・ ui ・ physics)・文書・サンプル・VS Code 拡張。ビルド結果は ~/.goose (GOOSE_HOME) に置く
• 標準ライブラリ: 14 モジュール。すべて読める Goose で書かれている。gfx は SDL3 の GPU API、physics は Box3D、ui は Nuklear の上に作られている
• パッケージ: import name from "owner/repo@v1"; で git のリポジトリを取得し、~/.goose にビルドする
• ソースからのビルド: CMake 3.27 以降、C++20 のコンパイラ、テストとサンプルの実行用に Python 3

C++・Rust・Go・JavaScript との比較

観点ごとに並べる。Goose の欄は公式資料の記載、他の言語の欄は一般に知られた言語の性質。公式ベンチマークに含まれる比較先は C++ と Rust だけで、Go と JavaScript は含まれない (第 8 章)。

Goose 以外の列は、当資料では実機で確かめていない一般知識。数値の比較ではなく、設計の違いを並べたもの。

解放を、いつ、誰が決めるか

ぶら下がった参照を、どう防ぐか

Go と JavaScript について

公式ベンチマークに Go と JavaScript の比較はない。確認した 5 つのベンチ群の README (plb ・ plb2 ・ kostya ・ kostya2 ・ bddicken) にも、Go や JavaScript と比べた記述は見つからなかった。比較先はいずれも C と C++ と Rust。

実測するなら

提案だけで、まだ実施していない。同じアルゴリズムを Goose ・ C++ ・ Rust ・ Go ・ Node.js で書き、全体の経過時間と最大メモリを同じ条件で測る。土台には、作者が Goose 版を用意している plb2 の 4 タスク (nqueen ・ matmul ・ sudoku ・ bedcov) が使える。Go と Node.js がこの環境に入っているかは未確認。

性能の主張とその読み方

数値はすべて、リポジトリの bench に置かれた作者側の測定結果 (2026/10/16 生成)。当資料では再計測していない。

全体の結果 (16 本の幾何平均)

ピークメモリは、慣用的な C++ に対して 1.95 倍、熟練者の C++ に対して 1.32 倍、最良の安全な Rust に対して 1.25 倍少ない (いずれも Goose が少ない側)。

16 本の内訳 (Rust との比較)

勝つところと負けるところ

読むときの注意

• 作者側の測定。1 台のマシンで、コア固定なし。差の小さい項目は誤差の範囲で、summary も同じ注意を書いている
• 「慣用的な C++」の定義は、unique_ptr ・ vector<string> ・ unordered_map ・ std::variant を素直に使う書き方。「熟練者の C++」は、予約済みアリーナと添字・string_view ・ 平坦なオフセット・オープンアドレス法・CSR を使う書き方。倍率は、この定義に左右される
• 集計は「最速の Goose 実装」の寄せ集め。比較ごとに最速の Goose 実装を選び、メモリは別に最小の実装を選ぶ。1 つの実装がすべての最良値を満たすわけではない (summary の記載)
• Rust は rustc 1 種類 (LLVM)。Goose と C++ は MSVC と clang の 2 種で比べている
• 日付をまたぐ比較は原因を特定できない。空プロセスの床や MSVC の版が前回の報告から変わっていて、差のすべてを Goose の改善とは言えない、と summary 自身が書く

ほかのベンチ群

作者は、既存の多言語ベンチマークの Goose 版も bench に置いている (plb ・ plb2 ・ kostya ・ kostya2 ・ bddicken)。各 README を読んだ範囲では、比較先は C と C++ と Rust。plb2 は nqueen ・ matmul ・ sudoku ・ bedcov の 4 タスクで、C は clang -O3 -fwrapv -flto、Rust は opt-level=3、Goose が出す C も clang -O3 でビルドする。出力は C の結果と照合してから時間を測る。

動くのか (確認した範囲)

動く。リリース版の goose.exe で、同梱のサンプル 31 本を実行し、期待出力との一致を確認した (JIT で 30 本、ネイティブビルドで 31 本)。確認できたことと、できなかったことを分けて示す。

サンプルの内容

ファイル名からの分類 (当方の整理)。「小さな言語の紹介」にとどまらず、グラフィックスやゲームまで含む。

限界と向き不向き

README が挙げる制限

• データがどこに住み、誰が所有し、スコープがどこまで続くかを、書き手が考える必要がある。多くは「データを組み立てる関数が所有者」で追加の作業は要らないが、そうでないときは slot_pool か slice_pool を使う
• 再帰関数は、再帰呼び出しをまたいで伸長できるデータを持てない。作業用のデータは呼び出しの前に終え、呼び出しより長く生きるデータはプールとして渡す
• 可変サイズの要素を持つ配列は、走査はできるが添字では引けない。固定モードの enum は中身を指せず、可変モードの enum は上書きできない。この選択はコンテナごとに決める
• エスケープするクロージャ・関数ポインタ・ADT のタグ以外の動的ディスパッチはなく、全プログラムのコンパイルだけに対応する
• プールへ返したのにまだ参照されている場所は、次の持ち主が置いた値を読む。論理的なバグだが、メモリ破壊にはならない

結論

• どういう言語か: ヒープと GC を持たず、データスタックと「動かない参照」で、注釈なしにメモリ安全を狙う C 出力のシステム言語
• 動くのか: 動く。リリース版の goose.exe で、同梱サンプル 31 本が期待出力と一致した (JIT で 30 本、ネイティブで 31 本)。3 OS の CI も成功している。性能と安全性の保証は検証していない
• 他言語との違い: C++ と Rust にはベンチマーク上の比較がある (作者側の測定)。Go と JavaScript とは、設計の違いを定性的に並べただけで、実測の比較はない
• 採るかどうか: 実験として面白く、特定の用途 (構造データの大量処理) には筋が良い。業務の基盤にするには、若さとライブラリ資産の少なさが壁になる

次の一手 (提案)

1. サンプルのうち数本の出力を人が読み、仕様どおりか確かめる (期待出力は実装から作れるため)
2. 同じアルゴリズムを Goose ・ C++ ・ Rust ・ Go ・ Node.js で書き、時間とメモリを同条件で測る
3. 自分の用途に近い小さなプログラムを 1 本書き、制約が障害になるかを見る

同名の別物

• goose-lang/goose: Go のサブセットを Rocq (Perennial) へ変換する検証ツール。言語ではない
• calico32/goose: Go の上に作られた小さな言語
• pressly/goose: データベースのマイグレーションのツール
• Block 社の goose: AI エージェント

出典

• aardappel/goose の README
• チュートリアル
• ベンチマークの全結果 (bench/results.md) ・ 要約 (bench/summary.md)
• plb2 の Goose 版 (bench/plb2/README.md)
• サンプルの案内 (samples/README.md)
• リリース v2026.3
• リポジトリの値 (星・コミット数・CI の状況) は 2026/11/01 に GitHub API で取得

課題

• 課題 (issues)