確かに、いい観察だね。もう一つの観察としては、その82%がデバッグ情報だってこと。-OReleaseSmall -fno-stripだと580Kの実行ファイルができるけど、-ODebug -fstripだと1.4Mの実行ファイルになる。zigのx86バックエンドは、このzig対応のlldbフォークを使うとデバッグ体験がかなり良くなるよね：https://github.com/ziglang/zig/wiki/LLDB-for-Zig 今のところコンパイル時のロジックをステップ実行できるかは覚えてないけど、最近その話をしたばかりだよ。

ホットコードスワッピングはゲーム開発にとって大きな進展だよ。Zigが基本的にコンパイラフラグでそれをサポートするっていうのはすごい。clangもそれやってみてよ。

comptimeのパフォーマンス改善については、何をするべきか分かってるよ。ずいぶん前にブランチを作り始めたんだけど、残念ながらセマンティック分析のコードをたくさん再構築する必要があるんだ。これは絶対にやらなきゃいけないし、やるべきことなんだけど、他の優先事項と競合してるんだよね。

comptimeの遅さって本当に問題なの？今、JSON-RPCライブラリを作ってて、JSONリクエストを任意の関数にディスパッチするためにcomptimeをめっちゃ使ってるんだ。厳格な静的型付けのせいで、実行時に任意のパラメータを持つ関数に動的にディスパッチする方法がないんだよね。見つけた唯一の方法は、コンパイル時にcomptimeを使って関数の型マッピングを考えることだった。これ、任意の関数ごとにcomptimeされたコードのコピーが増えて、コードサイズが膨れ上がるのは確実だわ。

カスタムバックエンドを作るのは簡単なの？まだ見てないけど、ちょっと実験してみたいんだ。具体的には、AIRを使ってメモリ安全レポートを生成するバックエンドを作れると思うんだ。（未定義の値を使ってるか、スタックポインタが逃げてるか、解放後に使ってるか、ダブルフリー、エイリアスxorミュートを特定できるようにね）

URCLが俺を迷宮に引き込んでる。まだ深くは見てないけど、最も面白いシナリオは、Minecraftのために作られたIRが言語の有効なコンパイルターゲットになることだな。

Zigのパッケージ管理はRustよりも手動で、CLIを使ってパッケージのURLを取得してから、ビルドスクリプトでモジュールをインポートする必要があるんだ。これには利点もあって、任意のアーカイブに依存できるから、たくさんのZigパッケージがCライブラリのビルドスクリプトと未修正のtarballリリースに依存してるよ。でも、初心者にはちょっと難しいかもね。SDL3にはネイティブのZigラッパーがあるよ：https://github.com/Gota7/zig-sdl3 それとCライブラリ/APIのもっと基本的な再パッケージも：https://github.com/castholm/SDL QuickJSについては、唯一の選択肢はC APIだね：https://github.com/allyourcodebase/quickjs-ng ZigはCパッケージを直接使うのがすごく簡単だけど、Zigの型はかなり厳密だから、APIとやり取りする時にはたくさんキャストしなきゃいけないよ。

Zigが自分自身を75秒でコンパイルできるなんて、マジで驚きだわ（llvm使っても）。

dmd Dコンパイラは自分自身をコンパイルできる（デバッグビルド）：実行時間 0m18.444s ユーザー 0m17.408s システム 0m1.688s 古いプロセッサで（速すぎて全然アップグレードしてない）：cat /proc/cpuinfo プロセッサ : 0 ベンダーID : AuthenticAMD CPUファミリー : 15 モデル : 107 モデル名 : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ ステッピング : 2 CPU MHz : 2299.674 キャッシュサイズ : 512 KB 物理ID : 0 シスブレッド : 2 コアID : 0 CPUコア : 2 apicid : 0 初期apicid : 0 fpu : yes

LLVMってJuliaの公開APIの一部と見なされてるんじゃないの？@code_llvmみたいなマクロがあって、実際にIRを見せてくれるし。

Juliaは実質的にLLVMにがっちり固定されてる。エコシステムの大部分が、インストリンシックや自動微分（Enzyme）、GPUコンパイルのためにLLVMに依存してるからね。BaseやCoreは言うまでもない。コンパイラはかなりリターゲット可能で、これは今も活発に取り組まれている分野だよ。だから、将来的にはZigが言語の一部のための代替コンパイラとして考えられるかもしれないね。

それがコンパイル時間を短縮する方法になるかもだけど、Julia側にはまだやることがたくさんあると思う。もっと細かいコンパイルキャッシュとか、無効化を防ぐためのツールが必要だし、ワールドスプリッティング最適化の削除、コンパイラ内でのマルチスレッドの活用、具体的なシグネチャの自動プリコンパイル、コンパイル時にコードをホットスワップするような怠惰なコードの生成とか。

リンクを読んでみたけど、asyncは戻ってこないか、少なくとも2028年までは無理そうだね。

その辺は全部整理できたよ。今後2〜3ヶ月でみんなに面白いアップデートができると思う。I/Oをゼロからやり直してるところで、ほとんど標準ライブラリの作業だね。

これはZigにとって素晴らしいことだと思う。この方向性がRustとの比較での主な差別化要因になるんじゃないかな。ちなみに、Rustでもcraneliftを使った似たような取り組みがあるよ： https://github.com/rust-lang/rustc_codegen_cranelift

それについてググってみるね： https://ziglang.org/documentation/0.14.1/

思いつくままにいくつか挙げると：

• 複数の難解なツールや言語を使わない統合ビルドシステム
• Zigのスライスは長さが分かるけど、Cの配列はバッファオーバーフローの問題がある
• 明示的なオプショナル型があって、必ずチェックしなきゃいけない。ヌルポインタは許可されてない（Cコードと統合する時は、その型が明確に示してくれる）
• 列挙型、タグ付きユニオン、"switch"式に対する徹底的なチェックが強制される
• エラーハンドリングが明示的で、関数はエラー（列挙型の値）を返すから、呼び出し側は何らかの形で対処しなきゃいけない。Cでは、関数がエラーを示すために整数を返すことがあるけど、それを完全に無視してもいい。言語に組み込まれたエラーとデータを返す標準的な方法が欠けてる（エラー構造体をパラメータで渡すパターンは無理やり感があるから、特別な構文が必要だと思う）
• "defer"や"errdefer"ブロックで関数の返却後やエラー時のクリーンアップ
• マクロの代わりにコンパイル時コード生成（Zigで）や型リフレクション（@typeInfoなど）
• 呼び出し側がライブラリにアロケータを渡すことで、メモリの割り当て方法や場所を決定することが多い
• 一般的なアロケータを使うだけでメモリリークを見つけやすい（少なくとも初心者には）

プログラミングを始めてからずっと高級言語を使ってきて、Cやその周辺のエコシステムの難解で直感に反する部分が嫌いだった私にとって、Zigはシステムプログラミングを楽しめる形で始めさせてくれた。