ハクソク

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

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

100日前原文(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の実装を待ってるよ。

Zigは好きだな。たくさんの素晴らしい機能が連携してるし。ただ、v1に達する頃にはRustがC/C++の領域を奪っちゃうんじゃないかって心配がある。とはいえ、Zigはメインストリームの言語になると思うし、v1以降はもっと注目されるようになるんじゃないかな。でも、その頃には実際に人々がコーディングしてるかどうかも問題だよね。

└

Rustは「C/C++の上位互換」ってわけじゃないと思う。全然違う新しいタイプの言語だよ。面白いけど、かなり異なる。逆にZigは、少なくとも私には（意見注意）、明らかに「Cの上位互換」だと思う。Cをコンパイルすることすらできるし！LLMがCをZigに変換するのが得意になると思うよ。> その頃には実際に人々がコーディングしてるかどうかも問題だよね。LLMは責任を持たないから、コードが生成されても人間がそれを評価しなきゃいけない。Zigの評価はCよりも簡単だと思うから、AI支援プログラミングの未来においてこの言語のセールスポイントになると思う。

└

それについては心配しなくていいと思うよ。まだまだ書かれるべきソフトウェアはたくさんあるし、いろんな言語でね。むしろ、Rustの成功は新しい言語が新しい何かを提供すれば成功する可能性があるってことを示してると思う。Zigにとっての追い風は、AIを使って既存のコードベースをテスト付きで新しい言語に翻訳するのが今まで以上に簡単になったことだね。

└

v1に達する頃にはRustがC/C++の領域を奪っちゃうんじゃないかって心配がある。Rustはかなり古い言語だけど、まだ採用率が低いから、あまり心配する必要はないと思う。ただ、だからといってZigが選ばれる選択肢になるとは限らないし、安定しないのは良い兆候じゃないね。Rustの採用率を考えると、まだ発明されていない言語が一般的な言語の採用率で普通に採用される可能性もあるし、簡単に追い越すことができるかも。> その頃には実際に人々がコーディングしてるかどうかも問題だよね。これはもっと大きな問題かもしれないね。 :)

└

より説得力のあるシナリオは、Rustのunsafeサブセットが今のZigと同じくらい使いやすくなることだと思う。ただ、安全なコードとの適切な相互作用に関しては潜在的な課題が残るけど。それには、言語や標準ライブラリの機能を根本的に再考し、「これが人工的な障害を作っているのか、あるいはunsafeなコンテキストで慣用的に使おうとしたときにUBを引き起こすのか？」と問い直す必要がある。その場合、もっと柔軟で「Cっぽい」機能を考え出す必要がある。大変な作業だけど、十分可能だと思う。

└

RustとZigはターゲットオーディエンスに関してあまり重ならないと思う。例えば、Rustに惹かれる人はZigがひどいと感じるだろうし、その逆もまた然り。RustはCやC++を意味のある形で置き換えることは決してないと思う。せいぜい新しいコードが新しい言語で書かれるだけだし（Rustはその中の一つに過ぎないし、新しいプロジェクトで使われる言語にはCやC++も含まれるけど、頻繁には使われないかもしれない）。「ポップスター言語」の時代は終わったと思う。プログラミング言語の未来は非常に多様で、それは良いことだね。

Zigがフリースタンディングターゲットを真剣に扱ってるのがいいね。0.16はフリースタンディングコードの再利用性がさらに良くなりそうだ。