Zig の概要

Andrew Kelley 氏が 2016 年に始めた言語。非営利の Zig Software Foundation が開発する。C の置き換えを狙い、C と同じ領域をより安全・明快に書けるようにする。

特徴

• 隠れた制御フローが無い。暗黙の関数呼び出し・メモリ確保・例外・演算子オーバーロード・マクロを持たない
• 手動メモリ管理。GC は無く、確保する関数には allocator を引数で渡す
• comptime。コンパイル時に Zig のコードを実行でき、ジェネリクスやメタプログラミングを担う
• エラーは値。例外は無く、エラー共用体型で返す
• 安全性チェック。Debug / ReleaseSafe では範囲外アクセスや整数オーバーフローを実行時に検出する
• C との親和性。@cImport で C ヘッダを直接読む。zig cc は C/C++ のクロスコンパイラとしても使える
• ビルドも Zig で書く。build.zig を使い、make や CMake は要らない

現状

• 1.0 前。版ごとに言語と標準ライブラリに破壊的変更が入る
• 0.16.0 で I/O をインターフェースとして扱う形が入った
• 手元に入れた Zig は zig version で 0.17.0 と確かめた。0.17.0 が最新の安定版で、2026-10-01 に出たという情報は、第三者のサイトの記述で、公式サイトでは確かめていない

C ・ Rust との比較

基本構文

記号の意味

制御構文

const a: i32 = 10;                  // const は変えない、var は変える
const c = if (a > 5) "大" else "小"; // if は式になる（三項演算子の代わり）

const maybe: ?i32 = 42;
if (maybe) |v| { _ = v; }           // 値があるときだけ取り出す

var i: usize = 0;
while (i < 3) : (i += 1) {}         // : ( ) は毎回の後処理
while (it.next()) |item| { _ = item; } // null が返るまで回す

for (0..10) |n| { _ = n; }          // 範囲・配列・スライスを回す。C 形式の for は無い
for (arr, 0..) |x, idx| { _ = x; _ = idx; } // 要素と添字
for (arr) |*p| { p.* += 1; }        // ポインタで受けて書き換える

const s = switch (a) {              // 全部の値を網羅しないとコンパイルエラー
    0 => "zero",
    1...9 => "small",
    else => "big",
};
defer cleanup();                    // スコープを出るときに必ず実行する

関数

fn add(a: i32, b: i32) i32 { return a + b; }
fn parse(s: []const u8) !u32 { ... }             // エラーを返しうる
fn max(comptime T: type, a: T, b: T) T { ... }   // 型を引数で受ける（ジェネリクスの代わり）

• 関数はすべて普通の同期関数。中断・再開できる特別な関数は無い
• クロージャは無い。状態は構造体に持たせる
• 値を捨てられるのは void 型の式だけ。戻り値を使わないなら _ = f(); と明示する

メモリ管理

GC は無く、確保も解放も手動で行う。メモリを確保する関数は allocator を引数で受け取る。確保の仕方は呼び出し側が決める。

fn makeList(alloc: std.mem.Allocator, n: usize) ![]u32 {
    return try alloc.alloc(u32, n);   // 失敗すると error.OutOfMemory
}

pub fn main() !void {
    var gpa = std.heap.DebugAllocator(.{}){};
    defer _ = gpa.deinit();            // 終了時にリークを報告する
    const alloc = gpa.allocator();

    const list = try makeList(alloc, 10);
    defer alloc.free(list);            // 確保した直後に解放を書く
}

allocator の選び方

言語リファレンスの「Choosing an Allocator」に挙がっているもの。

Rust との違い

Rust はコンパイル時に所有権を検査するが、Zig は検査しない。解放後の使用や二重解放は、Debug ビルドの実行時チェックや DebugAllocator で見つける。Bun が Rust へ移った主な理由もここにある（「Zig で書かれたプロジェクト」の章）。

エラー処理

例外は無い。エラーは戻り値として、エラー共用体型 E!T で返す。

const ParseError = error{ Empty, TooLong };  // エラー集合を定義する

fn check(s: []const u8) ParseError!void {
    if (s.len == 0) return error.Empty;
    if (s.len > 10) return error.TooLong;
}

fn run() !void {
    try check("abc");                  // エラーなら呼び出し元へ返す

    check("") catch |err| switch (err) { // その場で処理する
        error.Empty => {},
        error.TooLong => {},
    };

    const n = std.fmt.parseInt(u8, "x", 10) catch 0; // 失敗したら既定値
    _ = n;

    if (check("x")) |_| {} else |err| { _ = err; } // if でも分けられる
}

fn open(alloc: std.mem.Allocator) !*Res {
    const r = try alloc.create(Res);
    errdefer alloc.destroy(r);         // この後でエラーが返ったときだけ実行する
    try r.init();
    return r;
}

• エラーは黙って捨てられない。値を捨てられるのは void だけなので、try ・ catch ・ if のどれかで扱う
• エラーは列挙値のようなもので、メッセージなどの情報は持たせられない。詳しい情報は別の引数で返す
• エラーリターントレース。main からエラーが返ると、エラーが通ってきた経路を表示して終了コード 1 で終わる
• unreachable と @panic は回復できない停止で、エラー処理とは別

並行処理と非同期 I/O

コルーチン・goroutine・generator

async / await が外された理由

• 0.10 までは言語のキーワード（async / await / suspend / resume）があった
• Zig 自身で書いた新しいコンパイラでは、この機能が動かなかった。0.11.0 で使えなくなり、2022 年 12 月に言語リファレンスからも消えた
• 言語リファレンスが挙げた未解決の問題は 4 つ
  • LLVM が async 関数を最適化できない
  • 他社製のデバッガで async 関数をデバッグできない
  • 取り消し（cancel）をどう扱うか決まっていない
  • async 関数のポインタがあると、スタックの大きさが決まらない
• 2025 年 7 月、キーワードは正式に削除された。言語に async / await のキーワードは戻さず、I/O の実装を支える低水準の仕組みとして入れ直す、という方針が示された

代わりの仕組み（0.16 の std.Io）

allocator を引数で渡すのと同じように、I/O を行う関数は io を引数で受け取る。並行に動かしたいところで io.async() を呼ぶと future が返り、future.await(io) で結果を受け取る。

fn work(io: std.Io) !void {
    var f = io.async(fetchA, .{io});
    defer f.cancel(io) catch {};   // 取り消しと後始末
    const r = try f.await(io);
    _ = r;
    try io.sleep(...);             // タイマ。待つのも io を通す
}

• 見た目は普通のブロッキングするコードと同じ。同じコードを、同期でも非同期でも動かせる
• 同時に動くことが必要なときは io.concurrent() を使う
• 0.16 で Clock ・ Duration ・ Timeout の型が入った。タイムアウトは、処理と sleep を競わせる形で書く例がある
• network は std.Io.net にある。0.16 で動く完全な例は見つけていない

速度

実行速度

LLVM を最適化に使うため、ReleaseFast で作ったバイナリは C ・ Rust と同程度になる。2021 年の比較スレッドでは 6 本中 4 本で Rust が上回ったが、差は小さく、マイクロベンチマークでは優劣を決められないと結論している。速さを分けるのは言語ではなく、メモリ確保の仕方やデータ配置といった書き方である。

コンパイル速度

Debug ビルドは、LLVM の機械語生成に時間がかかり、遅いとされてきた。

Zig の時間の大半は LLVM のオブジェクト出力だった（Ziggit の投稿者 1 名の計測）。

その対策として、Zig は次の 2 つを進めている。

• 自前の x86 バックエンド: Debug ビルドで LLVM を使わない
• インクリメンタルコンパイル: 変えた関数だけを作り直す

再ビルドがミリ秒単位になったという報告や、75 秒が 20 秒に縮んだという報告がある。ただし二次情報で、計測の条件は確かめていない。2026 年 5 月には、ビルドシステムの改修で zig build -h が約 150 ミリ秒から約 14 ミリ秒になった。

Zig で書かれたプロジェクト

出典

• Zig Language Reference（master）
• Andrew Kelley: Zig's New Async I/O
• langref: eliminate dependencies on stage1（async を外したコミット）
• remove async, await, usingnamespace（#24362）
• DevClass: extremely breaking change to std.io
• Ziggit: the new Io interface
• Async/Await is finally back in Zig
• Zig 0.16 Io interface (youngju.dev)
• Ghostty: Zig 0.14 対応のコミット（DebugAllocator への改名）
• Ziggit: Newcomer: Getting into Allocators
• LWN: Zig 0.16.0
• How To Install Zig on Ubuntu 26.04 LTS
• zig systems programming pc
• Why is Zig much slower than other LLVM-based compilers?
• Why is zig build so slow?
• Is zig lang faster than rust?
• Zig 2026: compilación incremental y nuevos tipos
• Zig vs Rust 2026
• Inside Zig's Incremental Compilation
• Simon Willison's Weblog: zig
• Synadia and TigerBeetle Pledge $512,000 to the Zig Software Foundation
• roc rust to zig rewrite
• The Register: Anthropic's Bun Rust rewrite merged at speed of AI
• InfoQ: Bun Rewrites 535K Lines of Zig into Rust
• Wikipedia: Bun (software)
• river (Codeberg)
• uber/hermetic_cc_toolchain
• Uber: Bootstrapping Uber's Infrastructure on arm64 with Zig