1. 2026 年の Zig — Andrew Kelley のビジョンと産業適用

2026 年 5 月時点、Zig はまだ **1.0 ではない**。最新リリースは 2025 年 3 月の 0.14 だ。だが「0.x」ラベルに騙されてはいけない。Bun・TigerBeetle・Ghostty といった本気のプロダクトが既に Zig で出荷されており、数千の C/C++ プロジェクトが `zig cc` の一行でクロスコンパイラを差し替えている。

Zig のコアアイデンティティは Andrew Kelley(アンドリュー・ケリー)というソロ BDFL 一人と、その上に乗る Zig Software Foundation だ。Rust が Mozilla から財団へガバナンスを分散させた方向とは正反対で、Zig は意図的に一人の趣味を深く刻んだ言語である。結果として:

- **C に近いシンプルな表層**、しかし `comptime` という強力なコンパイル時メタプログラミング

- **隠れた制御フローなし** — オペレータオーバーロード、RAII、隠れアロケータなし

- **明示的なメモリ管理**、アロケータを関数引数として渡すパターン

- **`zig cc` / `zig c++`** — Zig が LLVM をバンドルし、本格的な C/C++ クロスコンパイラとして動く

- **`build.zig`** — Make/CMake/Bazel を置き換えるビルドシステム。ビルドグラフは Zig コードそのもの

産業適用は「まだ小さいが非常に真剣」。Bun が npm 流量に占めるシェア、TigerBeetle がフィンテックバックエンドに食い込む速度、Ghostty が macOS 開発者ターミナルのシェアを静かに削っていく勢い — この三つだけで「Zig はおもちゃではない」という証明には十分だ。

本記事は Andrew Kelley の設計哲学から始まり、0.14 の実体、0.15 / 1.0 ロードマップ、Bun / TigerBeetle / Ghostty を経て、comptime・アロケータ・ビルドシステム・zig cc・ZLS・Roc まで — 2026 年 5 月時点で Zig を真剣に見るべき理由と落とし穴を一度に整理する。

2. Zig 0.14(2025.3) — コンパイル速度と async 再設計待ち

2025 年 3 月 5 日、Zig 0.14 がリリースされた。主な変更:

1. **ネイティブ x86 バックエンドの安定化が進展** — LLVM をスキップしてデバッグビルドを高速化する作業。デバッグビルドのコンパイル時間が約 2 倍速くなるケースが報告された。

2. **`@import` 依存ツリーの単純化** — モジュールシステムがより直感的に。

3. **`std.Build`(ビルドシステム)API の刷新** — `build.zig` の書き味がまた変わった。0.13 → 0.14 の移行では `step.addArgs` などの API シグネチャ変更を要チェック。

4. **`async` / `await` は依然撤去中** — 0.11 で一時撤去された非同期機能は 0.14 でも未復帰。Andrew は「スタックレスコルーチンモデルを再設計する」と発言しており、その再設計が 1.0 前に入るかが最大の論点。

0.14 の雰囲気をコードで:

const std = @import("std");

pub fn main() !void {

var gpa = std.heap.GeneralPurposeAllocator(.{}){};

defer _ = gpa.deinit();

const allocator = gpa.allocator();

var list = std.ArrayList(u8).init(allocator);

defer list.deinit();

try list.appendSlice("Hello, Zig 0.14!\n");

try std.io.getStdOut().writeAll(list.items);

}

- `try` はエラー伝播、`defer` はスコープ終了時に実行

- `std.heap.GeneralPurposeAllocator` を直接生成し、`allocator()` でインターフェースを取り出す

- すべてのコレクションが `allocator` を受け取る — 隠れ alloc なし

0.14 の大局: **コンパイラが自分の足でより速くなっている**。Rust が `rustc` のコンパイル速度で叩かれているのと真逆の方向性だ。

3. Zig 0.15 / Zig 1.0 ロードマップ

2026 年 5 月現在、**0.15 はまだリリースされていない**。0.14 → 0.15 の間に入ると予想/議論されているもの:

- **ネイティブ x86 バックエンドのデフォルト化** — デバッグビルドで LLVM をバイパスするのがデフォルトに。リリースビルドは引き続き LLVM。

- **async/await 再設計** — Andrew が「I/O-driven concurrency」という新モデルを提案。要点は「スタックレスコルーチンではなく、明示的な io 引数による非同期」。例えば `fn read(io: *Io, ...) []u8` のような形。ライブラリが同意した時のみ非同期になる。

- **`std.Io`** — 非同期 I/O の標準インターフェース。まだ変動中。

- **インクリメンタルコンパイルの強化**

- **パッケージマネージャ(Zon)の安定化** — 0.14 で `build.zig.zon` が標準になり、0.15 でさらに磨かれる

**Zig 1.0 はいつ出るのか?** 誰も明言できない。Andrew は公式に「安定性を約束できる時点で 1.0 を出す」とだけ言っている。保守的に見れば 2027 年、楽観的にみても 2026 年下半期。Bun・TigerBeetle・Ghostty のような本気のユーザーは既に 0.x で出荷しており — 1.0 を待つのではなく、リリースごとに自分のコードを一緒に磨いている。

4. Bun ランタイム — Zig で書かれた最大の検証

Bun は Jarred Sumner(ジャレッド・サムナー)が作った JavaScript ランタイムだ。コアポジショニングは「Node.js の置き換え」、内部は **ほぼ全部 Zig で書かれている**。2024–2025 年にかけて Bun 1.x がリリースされ、1.1 / 1.2 を経て Node 互換性は 99% 近くに到達した。2026 年時点、Bun は「Zig という言語で本格的なインフラを書ける」最大の産業証拠だ。

Bun が Zig を選んだ理由:

- **コンパイル速度** — JS ランタイムは巨大な C++ 依存(JSC、V8)を引き込む必要があり、Zig はそれをビルドシステム内に綺麗にまとめる

- **`zig cc` で C/C++ 依存をクロスコンパイル** — Bun は macOS / Linux / Windows バイナリを一つのマシンから生成

- **アロケータ制御** — JS ランタイムのコアホットパスで alloc / free を手で管理

- **comptime** — `bun:ffi`、`bun:sqlite` のような module のボイラープレートをコンパイル時に生成

Bun スタイルのコード断片(簡略化):

// Bun の HTTP サーバホットパス(簡略化)

pub fn handleRequest(

arena: *std.heap.ArenaAllocator,

socket: *Socket,

req: *Request,

) !void {

var response_buffer = std.ArrayList(u8).init(arena.allocator());

try writeStatusLine(&response_buffer, 200);

try writeHeaders(&response_buffer, req);

try socket.writeAll(response_buffer.items);

}

- **アリーナアロケータ** — リクエスト単位でメモリを束ね、レスポンス完了時に arena ごと一気に解放。malloc / free 呼び出しがほぼゼロ

- **明示的なエラー伝播** — `try` ですべての I/O エラーを上に投げる

- **隠れ alloc なし** — `ArrayList` も `init(allocator)` で明示

Bun が示したこと: **小チーム(10 人以下)が Zig で Node クラスのインフラを作れる**。Rust より圧倒的にコード量が少なく、C より圧倒的に安全だ。

5. TigerBeetle — 分散会計 DB

TigerBeetle は Joran Dirk Greef が率いる金融用分散 DB。100% Zig で書かれ、単一目的が明確だ — **double-entry accounting transactions を OLTP 速度で処理する**。フィンテック / 決済システムの ledger バックエンドを狙う。

TigerBeetle が面白い理由:

- **NASA Power of 10 ルール** + **TIGER STYLE コーディングガイド** — 関数 70 行制限、再帰禁止、動的 alloc は起動時のみ、すべてのループに明示的境界、assert を多用

- **deterministic simulation testing** — VOPR(Viewstamped Operation Replication)という自製合意アルゴリズムを fault injection で数十億回シミュレート

- **シングルバイナリ、ゼロ依存** — `zig build` 一回でバイナリ一つが落ちる

- **performance** — ノード当たり毎秒 100 万トランザクションを目標

TIGER STYLE の一部をコードで:

fn transfer(ledger: *Ledger, from: AccountId, to: AccountId, amount: u64) !void {

assert(from != to);

assert(amount > 0);

const from_account = try ledger.lookup(from);

const to_account = try ledger.lookup(to);

assert(from_account.balance >= amount); // 事前条件を明示

from_account.balance -= amount;

to_account.balance += amount;

try ledger.commit();

}

- `assert` がコメントのように敷かれる — デバッグビルドで invariant を強制

- すべての alloc は起動時に完了、ホットパスには alloc がない

- 関数は短く、一つのことしかしない

TigerBeetle は「Zig がミッションクリティカルにも使える」産業証拠だ。フィンテック ledger は 1 円でもズレれば会社が潰れるドメインで、そこに Zig を賭けた。

6. Ghostty — Mitchell Hashimoto のターミナル

Ghostty は Mitchell Hashimoto(ミッチェル・ハシモト — Vagrant / Terraform の作者)が作った GPU 加速ターミナルエミュレータだ。2024 年 12 月に 1.0 がリリースされ、2026 年には macOS・Linux 両方で 1 級市民になっている。

Ghostty が Zig を選んだ理由:

- **クロスプラットフォームネイティブ UI** — macOS は Swift、Linux は GTK4。その間にあるコアロジックは Zig

- **comptime でターミナルシーケンスパーサを生成** — VT100 / xterm エスケープシーケンスをコンパイル時にルックアップテーブルへ展開

- **ゼロコピーレンダリング** — GPU テクスチャに直接書き込むため alloc を手で管理

- **Mitchell 個人の選択** — Terraform を Go で書いた人物が「次は Zig」と言ったのは事件だった

Ghostty が示すパターン:

const Cell = struct {

char: u21,

fg: Color,

bg: Color,

attrs: packed struct(u8) {

bold: bool,

italic: bool,

underline: bool,

_reserved: u5,

},

};

- **`packed struct(u8)`** — ビットレイアウトを明示。C ならマクロ / コメントでやることを言語が理解する

- **`u21`** — 正確に 21 ビット整数、Unicode コードポイント表現にぴったりの幅

Ghostty は「Zig で GUI アプリを作れる」証拠でもある。新しいシステム言語は通常 GUI で止まるが、Mitchell は「コアは Zig、プラットフォーム chrome はネイティブ」という答えを示した。

詳細比較は別記事(2026-05-16 ターミナルシェルツール)で扱った。

7. Zig ビルドシステム(build.zig)+ Zon マニフェスト

Zig は外部ビルドツールを使わない。Make・CMake・Bazel・Cargo がすべて消え、代わりに **`build.zig`** 一つが入る。つまり **ビルドスクリプトも Zig コード**だ。

典型的な `build.zig` の形:

const std = @import("std");

pub fn build(b: *std.Build) void {

const target = b.standardTargetOptions(.{});

const optimize = b.standardOptimizeOption(.{});

const exe = b.addExecutable(.{

.name = "myapp",

.root_source_file = b.path("src/main.zig"),

.target = target,

.optimize = optimize,

});

b.installArtifact(exe);

const run_cmd = b.addRunArtifact(exe);

const run_step = b.step("run", "Run the app");

run_step.dependOn(&run_cmd.step);

}

- `b: *std.Build` — ビルドグラフビルダオブジェクト

- `b.standardTargetOptions` — `-Dtarget=x86_64-linux-gnu` のようなオプションを自動で受け取る

- ビルドはデータではなくコード — for ループ、if 分岐、動的依存全て可能

Zon マニフェスト — `build.zig.zon`

0.11 から導入された Zig Object Notation。JSON 風だが Zig 構文。

.{

.name = "myapp",

.version = "0.1.0",

.minimum_zig_version = "0.14.0",

.dependencies = .{

.httpz = .{

.url = "https://github.com/karlseguin/http.zig/archive/abc123.tar.gz",

.hash = "1220abcdef...",

},

},

.paths = .{ "src", "build.zig", "build.zig.zon" },

}

- **`.hash` 必須** — content-addressed、依存が変わるとビルドが止まる

- **中央レジストリなし** — npm / crates.io 相当が存在しない。すべての依存が URL 直接参照

- これは意図された設計 — Andrew は「パッケージマネージャはセキュリティ表面が大きすぎる」と発言

トレードオフ:

- 長所: 依存グラフが暴走しない、誰かが left-pad 級の事故を起こせない

- 短所: discoverability が辛い — 「Zig 版 lodash」がどこにあるか自分で探す必要

8. Zig as C cross-compiler — 他のプロジェクトが Zig を使う理由

`zig` をインストールするとついてくる最強のツールが **`zig cc`** / **`zig c++`** だ。単なるラッパーではなく、**LLVM をバンドルした本格的な C/C++ コンパイラ**である。

Linux x86_64 上で macOS aarch64 バイナリを作る

zig cc -target aarch64-macos main.c -o main

Windows x86_64 へクロスコンパイル

zig cc -target x86_64-windows-gnu main.c -o main.exe

何が凄いか:

- **glibc バージョン指定可能** — `-target x86_64-linux-gnu.2.17` で RHEL 7 互換ビルド

- **libc バンドル** — Zig は musl、glibc、mingw のソースを一緒に持っている

- **単一インストール** — Zig を一つ入れれば、すべてのターゲット向けクロスコンパイラが揃う

産業利用:

- **uv(Python パッケージマネージャ、by Astral)** — wheel ビルドに `zig cc` を使用

- **TigerBeetle** — `zig build` が全プラットフォームバイナリを一つのマシンから生成

- **Bun** — 上述のように依存コンパイルに使用

- **gcc / clang 置き換え** — Drew DeVault などが自プロジェクトでツールチェーンを差し替えた事例

核心メッセージ: **Zig 言語を使わなくても Zig ツールは使うようになる**。クロスコンパイルというたった一つの機能のために。

9. Zig vs Rust 論争 — 違い

2026 年に「Rust vs Zig」は既に陣営戦だ。両者とも C/C++ の後継を自任する。だが質感が大きく違う。

| 軸 | Rust | Zig |

|---|---|---|

| メモリ安全 | borrow checker(コンパイル時強制) | アロケータ志向 + ランタイムチェック |

| Generics | trait + monomorphization | comptime |

| コンパイル速度 | 遅さで悪名 | 速い、自製バックエンドでさらに速く |

| Async | async/await(stabilized) | 一時撤去、再設計中 |

| 標準ライブラリ | 巨大 | 小さい(意図的) |

| ビルドツール | cargo | build.zig |

| 1.0 | 2015 年 5 月 | 未定(2026 下半期 〜 2027) |

| ガバナンス | 財団 + チーム | Andrew Kelley + ZSF |

| 学習コスト | 非常に急 | 急、だが質感が違う |

Zig の「borrow checker がなくて安全なのか?」への答え:

1. **アロケータを明示的に受け取る** — 誰がメモリを所有するかが関数シグネチャに書かれている

2. **ランタイム safety checks** — デバッグビルドで out-of-bounds、整数オーバーフロー、null deref が自動 panic

3. **`defer` / `errdefer`** — RAII ではないが決定的なクリーンアップ

4. **GeneralPurposeAllocator の leak detection** — デバッグビルドで leak が検出される

Andrew Kelley は「Rust の borrow checker は安全のために自由を捨てすぎる。Zig は明示性と単純性を選ぶ」と発言した。どちらも正しい。ドメイン次第で答えが違う。

10. comptime — Zig のキラー機能

`comptime` は Zig のコア差別化要素だ。**任意の Zig コードをコンパイル時に実行**でき、その結果を型や定数として使える。

10.1 Generics は関数だ

fn List(comptime T: type) type {

return struct {

items: []T,

len: usize,

pub fn append(self: *@This(), item: T) void {

// ...

}

};

}

const IntList = List(i32);

const StrList = List([]const u8);

- `T` は `comptime` 引数、型そのものを値として受け取る

- `List` は関数、呼び出すと型を返す

- C++ template、Rust generic と同じ仕事をする — しかし **言語内で 1 級市民**

10.2 コンパイル時コード実行

const lookup_table = comptime blk: {

var t: [256]u8 = undefined;

for (&t, 0..) |*v, i| {

v.* = @intCast(i * 2 % 256);

}

break :blk t;

};

- `comptime blk: { ... }` — このブロックがコンパイル時に実行され、結果が埋め込まれる

- ランタイムでは lookup_table は 256 バイトのデータとして存在

- C ならマクロ / 外部スクリプトに頼ることを、Zig は同じ言語内で

10.3 自分自身を検査するコード

fn serialize(value: anytype, writer: anytype) !void {

const T = @TypeOf(value);

const info = @typeInfo(T);

switch (info) {

.Int => try writer.print("{}", .{value}),

.Bool => try writer.print("{}", .{value}),

.Struct => |s| {

inline for (s.fields) |field| {

try serialize(@field(value, field.name), writer);

}

},

else => @compileError("unsupported type"),

}

}

- `@typeInfo` で型を introspect

- `inline for` はコンパイル時 unroll

- `@compileError` でコンパイル時失敗メッセージ

これは Rust の `proc-macro` + `serde` + `syn` がやっていることを、**言語レベルで** やっている。外部マクロなしで。

11. アロケータ志向プログラミング

Zig のメモリモデルは一文で要約される: 「**メモリを使うすべての関数は allocator を引数として受け取らなければならない**」。

pub fn readFile(allocator: std.mem.Allocator, path: []const u8) ![]u8 {

const file = try std.fs.cwd().openFile(path, .{});

defer file.close();

const stat = try file.stat();

const buffer = try allocator.alloc(u8, stat.size);

errdefer allocator.free(buffer);

_ = try file.readAll(buffer);

return buffer;

}

- アロケータを明示的に受け取る — 関数が何の alloc を使うか呼び出し側が分かる

- `defer` でファイルクローズ

- `errdefer` でエラー時のみ buffer 解放

標準ライブラリが提供する allocator:

| Allocator | 用途 |

|---|---|

| `std.heap.GeneralPurposeAllocator` | デバッグビルドで leak / double-free 検出 |

| `std.heap.page_allocator` | OS ページを直接 |

| `std.heap.c_allocator` | malloc / free |

| `std.heap.ArenaAllocator` | リクエスト単位でまとめて解放 |

| `std.heap.FixedBufferAllocator` | 事前確保バッファ |

| `std.testing.allocator` | テスト、leak 強制検出 |

**Arena パターン**が核心:

var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);

defer arena.deinit();

const alloc = arena.allocator();

// このスコープ内のすべての alloc は arena.deinit() 一発で解放される

const a = try alloc.alloc(u8, 100);

const b = try alloc.alloc(u8, 200);

// a、b 個別 free 不要

Bun の HTTP リクエスト処理、TigerBeetle のトランザクション処理がすべて arena パターン上で動く。**alloc 回数が減ることで平均性能が安定して速くなる**。

12. ZLS(Zig Language Server)

`ZLS` は Zig 公式ではないコミュニティ LSP だ。2026 年時点、VS Code・Neovim・Helix・Zed すべてで 1 級市民。

ZLS が提供するもの:

- **goto definition / find references**

- **autocomplete**(comptime 結果もある程度)

- **inlay hints** — 推論された型をインライン表示

- **diagnostics** — Zig コンパイラを呼び出してエラーをリアルタイム表示

- **rename refactoring**

注意点:

- ZLS は **Zig バージョンと合わせる必要がある**。0.14 用 ZLS、0.13 用 ZLS は別

- comptime 推論には限界がある — 特に `anytype` 引数

- 0.14 時点でも時々止まる — Rust analyzer レベルの安定性はまだ

設定(`.zls.json`):

{

"enable_inlay_hints": true,

"enable_argument_placeholders": false,

"warn_style": true,

"enable_autofix": true

}

13. Roc — 関数型の代替

Roc は Richard Feldman(リチャード・フェルドマン — Elm コミュニティ出身)が作った関数型システム言語だ。奇妙にも **Zig と一緒に語られることが多い**。理由:

- **Roc コンパイラが Zig で書かれている**

- **`roc build` も LLVM をバンドル** — Zig と同じアプローチ

- **関数型 + GC なし + ML 系構文** — Haskell の美観 + Zig の実行モデル

- **Andrew Kelley が公に応援**

Roc コードの一例:

greet : Str -> Str

greet = \name -> "Hello, \(name)!"

main =

Stdout.line! (greet "World")

- 関数型、パターンマッチング、型推論

- `!` で effect を明示 — Haskell の IO と似た発想

- GC なし、リファレンスカウント + opportunistic in-place mutation

2026 年時点、Roc はまだ 0.x。だが「Zig 上に作られた本気の ML 系言語」というポジションがあり、関数型を好む人に魅力的だ。**Zig エコシステムの多様性を示す事例**。

14. 韓国 / 日本 — ビルダー導入、Cybozu Zig 実験

14.1 韓国 — ビルダー(Builder)導入

韓国の SaaS ビルダー企業(Notion / Webflow 系ツールを作る会社)が、2025 年からコアレンダリングエンジンに Zig を実験的に導入し始めている。

- **理由 1**: WASM ターゲット — Zig は WASM を 1 級でサポート、結果バイナリが Rust より小さい場合が多い

- **理由 2**: `zig cc` で既存 C/C++ 依存を WASM に持ち込む — emscripten 依存を減らす

- **理由 3**: コアチーム規模が小さいスタートアップに合う — Rust 学習コストに対して入り口が良い

もちろんまだ小さい。JS / TS スタックが圧倒的。だが「WASM ターゲットのホットパス」では Zig 採用が増えている。

14.2 日本 — Cybozu(サイボウズ)Zig 実験

サイボウズ(Kintone を作るグループウェア会社)は、一部モジュールを Go → Rust → Zig へ移行する実験を公開した。結果:

- **Rust**: 安全だがコンパイル速度 + 学習曲線が問題

- **Zig**: コンパイルが速く、Go から移ったエンジニアも数日で読める

- **欠点**: 1.0 ではないのでバージョン更新ごとにコード修正が必要 — このコストを受け入れられるかが判断ポイント

富士通・NTT の一部インフラチームも zig cc だけを導入してビルドパイプラインを単純化した事例がある — 「**言語は使わないがツールは使う**」パターン。

15. 誰が Zig を選ぶべきか — システム / 組み込み / C 置き換え

以下のドメインなら真剣に Zig を検討せよ:

1. **C/C++ プロジェクトのビルドシステム置き換え** — Make / CMake に飽きた人。`zig build` + `zig cc` で一気に綺麗になる

2. **クロスコンパイルが必要な CLI ツール** — Bun が示したパターン

3. **組み込み / OS 開発 / ファームウェア** — `no std`、正確なビットレイアウト、アロケータ制御が必要な場所

4. **WASM ターゲットのホットパス** — ビルダーケース

5. **金融 / ミッションクリティカルバックエンド** — TigerBeetle ケース、ただし TIGER STYLE 級のディシプリンが必要

避けるべき場所:

- **Web バックエンド(CRUD)** — Go・Node・Rust の方がはるかに速く書ける

- **データサイエンス / ML** — Python エコシステムが圧倒的

- **GUI アプリ全体** — コアだけ Zig、chrome は別(Ghostty パターン)

- **長期安定性が決定的な場所** — 1.0 がまだ出ていない。バージョン移行コスト覚悟が必要

**一行結論**: 2026 年の Zig は「**真剣な実験段階の真剣な言語**」。Bun・TigerBeetle・Ghostty が 1.0 前に出荷していること自体が証拠だ。1.0 を待たず、負担の小さい場所で一度試してから判断すればいい。

16. 参考 / References

- Zig 公式サイト: [https://ziglang.org/](https://ziglang.org/)

- Zig 0.14 リリースノート: [https://ziglang.org/download/0.14.0/release-notes.html](https://ziglang.org/download/0.14.0/release-notes.html)

- Zig Software Foundation: [https://ziglang.org/zsf/](https://ziglang.org/zsf/)

- Andrew Kelley ブログ: [https://andrewkelley.me/](https://andrewkelley.me/)

- Zig 言語リファレンス: [https://ziglang.org/documentation/master/](https://ziglang.org/documentation/master/)

- Zig ビルドシステムガイド: [https://ziglang.org/learn/build-system/](https://ziglang.org/learn/build-system/)

- Zon パッケージマニフェスト: [https://ziglang.org/learn/build-system/#zig-package-manager](https://ziglang.org/learn/build-system/#zig-package-manager)

- Bun: [https://bun.sh/](https://bun.sh/)

- Bun GitHub: [https://github.com/oven-sh/bun](https://github.com/oven-sh/bun)

- TigerBeetle: [https://tigerbeetle.com/](https://tigerbeetle.com/)

- TigerBeetle 設計ドキュメント: [https://docs.tigerbeetle.com/](https://docs.tigerbeetle.com/)

- TIGER STYLE コーディングガイド: [https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md](https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md)

- Ghostty: [https://ghostty.org/](https://ghostty.org/)

- Ghostty GitHub: [https://github.com/ghostty-org/ghostty](https://github.com/ghostty-org/ghostty)

- ZLS(Zig Language Server): [https://github.com/zigtools/zls](https://github.com/zigtools/zls)

- Roc 言語: [https://www.roc-lang.org/](https://www.roc-lang.org/)

- uv(Astral、zig cc 使用): [https://docs.astral.sh/uv/](https://docs.astral.sh/uv/)

- "Zig が C/C++ を置き換えられるか" Andrew Kelley 講演: [https://www.youtube.com/results?search_query=andrew+kelley+zig](https://www.youtube.com/results?search_query=andrew+kelley+zig)

- Bun 内部 Zig 利用パターン記事: [https://bun.sh/blog](https://bun.sh/blog)

- Zig コミュニティ Discord: [https://discord.gg/zig](https://discord.gg/zig)