ハクソク

世界を動かす技術を、日本語で。

Zig – io_uringとGrand Central Dispatchのstd.Io実装が追加されました

2026年2月14日原文(ziglang.org)

概要

  • Zigのmainブランチに2026年の主要な変更点をまとめた内容
  • std.Ioでio_uringとGrand Central Dispatchの実装が追加
  • パッケージ管理ワークフローが2点強化
  • WindowsでKernel32.dllをバイパスする新たな方針
  • 各機能の詳細と使い方、注意点を解説

2026年2月13日: io_uringとGrand Central Dispatchのstd.Io実装

  • io_uring と Grand Central Dispatch の std.Io 実装がmainブランチに追加
  • これらは ユーザ空間スタック切り替え （ fibers や グリーンスレッド とも呼ばれる）を基盤とする
  • std.Io.Evented を使用することで、アプリケーションで簡単にI/O実装の切り替えが可能
  • 現時点では 実験的 であり、以下の課題が残る
    • エラーハンドリングの改善
    • 不要なロギングの削除
    • IoMode.evented利用時のパフォーマンス低下の原因特定
    • 未実装関数の対応
    • テストカバレッジの拡充
    • 関数ごとの最大スタックサイズ取得ビルトイン関数の追加
  • コード例
    • Threaded I/O実装 と Evented I/O実装 の切り替えが可能
    • app関数の内容はどちらも同一
  • Zigコンパイラ自体も std.Io.Evented で動作確認済み
  • パフォーマンス低下 が未解決のため、本番利用は非推奨

2026年2月6日: パッケージ管理ワークフローの2つの強化

  • 依存パッケージ はプロジェクトルートの zig-pkgディレクトリ にローカル保存
    • .gitignore等で バージョン管理対象外 にする推奨
    • 自己完結型ソースtarball として配布・オフラインビルド・アーカイブが容易
  • 依存パッケージのグローバルキャッシュ
    • ~/.cache/zig/p/ 配下に 圧縮ファイル で保存
    • パスフィルタ 後に再圧縮されるため、 複数PC間での共有 が容易
    • 将来的には P2Pトレント配布 も計画
  • --forkフラグ の追加
    • zig build --fork=[path]で依存パッケージを 一時的にローカルのフォークへ切替
    • CLIフラグ なので、解除も簡単
    • 対象プロジェクトが見つからない場合は エラー、マッチした場合は リマインダー表示
    • エコシステム破損時のワークフロー改善
      • ビルド失敗時に--forkで修正・テスト
      • 修正後はパッチのアップストリーム提出も容易

2026年2月3日: Kernel32.dllバイパスの方針

  • Windows のAPIは DLL階層構造 で設計
    • kernel32.dllは高レベルラッパー、実際の処理はntdll.dllが担当
    • kernel32.dll経由は 余計なヒープ確保・失敗要因・CPU使用・バイナリ肥大化 の原因
  • Zig標準ライブラリ は ネイティブAPI優先方針 へ
    • 例：乱数取得ではadvapi32.dllのSystemFunction036ではなく、より低レベルAPIを利用
  • メリット
    • 効率的なリソース利用
    • 予期せぬ失敗の回避
    • 実行速度と安定性の向上
  • 今後もkernel32.dll依存削減を継続

他の年の変更点は Devlog archive page で参照可能

Hackerたちの意見

これらはユーザースペースのスタック切り替えに基づいていて、時々「ファイバー」とか「スタックフルコルーチン」、あるいは「グリーンスレッド」と呼ばれることもあるよ。

しばらくMacOSの内部を見てなかったけど、GCDを使い続けてるのを見て嬉しい。並列処理にはいい中間地点だね。

Zigが1.0に到達するまで追いかける価値はない気がする。これ、たぶん5回くらい書き直されるんじゃないかな。もし何かの理由でZigを積極的に使ってるなら、いいニュースかもしれないけど、ここにいる大多数の開発者にとっては、クルディーガで雨が降ってるって発表されてるようなもんだよね… だから、うん。しばらくZigを追ってたけど、1.0のリリースを見ることはないと思う。

└

NHのユーザー名としてグラフィックなセックススラングが受け入れられるとは思わなかったな。これは「~"おまんこを食べる"」って訳せるけど、「broûter」は草を食べる動物に使われる動詞で、かなりのボーボーを暗示してるんだよね。

└

参考までに、BunはZigで書かれてるよ（https://bun.sh/）。この言語は決して初期段階ではないね。

└

私の経験では、Zigの破壊的変更は多くのアプリケーションタイプにとってかなり管理しやすいよ。最近の破壊はほとんどがstdlibで起こるから、言語自体ではないしね。もしファイルの読み書きだけしたいなら、高レベルのファイルI/Oインターフェースはほぼ同じで、単に別の名前空間に移動しただけで、std.Ioポインタを渡す必要があるだけだよ。正直、厳格な後方互換性の要求で硬直化した言語よりも、'生きている'言語の方が好きだな。サードパーティの依存関係を新しいメジャーバージョンに更新する際も、コードを修正する必要があるのが普通だし（Zigではその破壊的変更がマイナーバージョンにあるけど、0.xでもそれは期待されてる）。実際、1.x以降もZigが非推奨インターフェースを積極的に削除してstdlibをスリムに保つ戦略を持っていてほしいな（たとえば、別のstdlibインターフェースバージョンを通じて、const std = @import("std/v1");みたいに、これらのバージョンは単一のコアstdlib実装の周りにスリムな互換性ラッパーになるかもしれない）。

└

典型的なHNの冷めたコメントだね。「この言語の変化は俺の好みを超えてる -- なんで誰が使うんだ？」興味がないなら、ダウンボートして次に進めばいいのに。なんで誰が積極的に使うのかを声に出して疑問に思うのは、無駄なバイトの使い方だよ。

ネガティブな意見とは逆に、Zigの改善努力には期待してるよ。今のところ、io-uringに強い言語はないからね。まあまあの選択肢はあるけど、現代的な非同期の楽しさを持ってるものはない。ここでいい解決策を見つけたら、かなりのアドバンテージになると思う。Rustは多くの面で素晴らしいけど、io-uringをうまくサポートするのはかなり厳しい道のりだったし、努力はまだちょっと原始的かな。Zigがこれをうまくやれたら素晴らしいね！ Zigには学び続けて、新しいものやより良いものを作り続けてほしいな。プロジェクトに対して保守的すぎて変化や改善を受け入れない人たちを喜ばせようとするよりもね。いいシステムを作るにはたくさんの学びが必要だし、フィット感や仕上がりを遊ぶことが大事だよ。Zigはいい仕事をしてると思う。感謝すべきだね。

└

低レベル言語で非同期処理を求める人が多いのは驚きだね。Goの非同期処理はすごくいいけど、Zigみたいな言語を選ぶ理由は、そういうことを明示的にコントロールしたいからなんだ。今、libxevを使ってio_uringの抽象化をしたZigプロジェクトを楽しく書いてるよ。

ネガティブなことを言いたくはないけど、これは未完成の実装についてのニュースだよ。これが完成したと見なされるには、まだたくさんの作業が必要なんだ。例えば、GCD版にはまだネットワーキングがないしね。これらが実装されるにつれて、インターフェースはインターフェースでなくなっていくし、vtableはどんどん大きくなっていく。これは標準実装に必要なものの現在のスナップショットに過ぎないよ。

└

投稿の最初でそれを認めてるの？ > 現在、std.Io.Eventedを使ってアプリケーションを構築することで、いじることができるようになってる。信頼性と堅牢性を持って使えるようになるには重要なフォローアップ作業が必要だから、実験的なものと考えるべきだね。それから、6つの重要な未解決の作業がリストアップされてるよ。

kqueueの実装を待ってるよ。

Hacker Newsで議論の続きを見る