汎用の非同期プリミティブを作ることに成功したら、元のタスクが何だったかはあんまり関係ないんじゃない？（非同期が必要なものであれば）それが汎用性のあることの暗示だよね？

このレイヤーはNATSクライアントから抽出されたわけじゃなくて、NATSクライアントがフラストレーションの元になってこのものが生まれたんだよね。

数年なんてあっという間だよ。Zigは十分に使える言語だし、使いたい人は使うし、使いたくない人は使わないよ。

個人的には、それはすごく間違ってると思う。Zigの言語は劇的に変わるわけじゃなくて、新しい、非常に強力なAPIを追加してるんだ。ほとんどのZigの要素がアロケーターを関数のパラメータとして受け取るのと同じように、IOを行いたい関数は、望ましい抽象を提供するオブジェクトを受け入れるようになるから、呼び出し元が理想的な実装を定義できるようになるんだ。つまり、コードをアップグレードしたり改善したりするのが嫌なら、Zigを使わない理由はないよ。今日書いたコードは明日も動くし、明日書くコードは新しいIOインターフェースを持つ可能性が高いけど、それはその標準の抽象を使いたいから。使いたくないなら、既存のコードはそのまま動くよ。今日のように、アロケートしたいけどAllocatorを渡したくないなら、どこからでもstd.heap.page_allocator.allocを呼び出せるしね。でも、その抽象がすごく便利だから、Zigはそれをすごく使いやすくサポートしてるから、みんなその改善されたAPIを提供するコードを書くんだ。ちなみに、0.15.2でほぼ安定している新しいReader/Writer APIに合わせて、すべてのコードをアップグレードするのが心配だったけど、既存のプロジェクトに数行追加するだけで済んだ。新しいAPIのおかげで、すごく良いコードになるから、たくさんの関数をリファクタリングすることを選んでるよ。可読性もパフォーマンスも両方良くなるしね。リファクタリングしなきゃいけないわけじゃないけど、古いAPIは問題なく動くし、新しいAPIは単に使いやすくて、パフォーマンスも良くて、読みやすくて理解しやすい。やりたいからやってるだけで、やらなきゃいけないわけじゃないよ。赤いdiffが一番良いってみんな知ってるし、新しいstd.Io APIは物事をやるのが簡単な方法を提供してる。でも、Zigのすべてのように、自分が書きたいコードを書くこともできるし、それを自分でやりたいなら、それも完全にサポートされてるよ！

ちょっと悪いアイデアかもね。著者のライブラリですら最新のZig IO機能を使ってないし、0.16で大きな変更を計画してるみたい。リポジトリのREADMEから: > さらに、Zig 0.16がstd.Ioインターフェースを持ってリリースされたら、それも実装する予定です。このランタイムで標準ライブラリ全体を使えるようにします。このライブラリとは関係なく、ZigでたくさんのIOをやるつもりなので、0.16を待つつもり。君の直感が別の判断をするかもしれないけど、それもいいよ。

何をしているかによるけど、I/Oに関することで、Zig 0.15で導入されたバッファードリーダー/ライターインターフェースを使うなら、あまり変わらないと思うよ。インターフェースの取得方法に変更が必要かもしれないけど、コードのコア部分はそのままだよ。

「私の印象では、物事が落ち着くのに数年かかると思っていたんだけど、それは間違い？」 2020年初めに数ヶ月Zigを使って（常に壊れる変更にやられて）その印象を持っていたんだ。だから「数年後にまた見てみよう」と決めて離れた。これが永遠にリファクタリングしているプロジェクトの一つになるんじゃないかって直感があったんだ。5年後の今、まだ1.0を待ちながら、状況に応じてGoやCを使っている。決してそこに到達しないとは言わないけど、これは単に早く出荷することよりも、最良の設計判断を優先している活気あるプロジェクトだよ。Cの代替としては、原則的にはその精神が正しい。ただ、エンジニアが永遠に洗練し続けることに対して免疫があるかはわからない。のんびり待つには素晴らしいプロジェクトだと思うよ（＝

実際、Zigのasync設計がハードウェアの呼び出し/戻りペアを使っているかどうかはわからない。Zigはもうかなり前から言語にasyncがないし、OPはユーザースペースでタスクスイッチングを実装したんだ。