アンドリュー・ケリーは僕のお気に入りの技術スピーカーの一人で、Zigは素晴らしいアイデアが詰まってる。彼はオープンソースプロジェクトのリーダーとしてもいいお手本みたいだね。

これが完全にオプションであってほしいけど、現実的にはそうならないだろうな。Rustみたいに、オプショナルな非同期サポートがある言語は、非同期がエコシステム全体に浸透しちゃうからね。色付きの関数があると、そうなるのは予想通りだよ。標準ライブラリはそこまで悪くないけど、前にチェックしたときは、実際にはブロックしないのに非同期関数がたくさんあったんだ。非同期は多くの人にとってうまく機能してるのは分かるし、スレッドを理解できない人が非同期を好むのも理解できる。生産的になれるパターンがあるのは素晴らしいよね！でも、僕には非同期はどうしても合わない。使うのが不安で、もう10年以上試行錯誤してるけど、結局うまくいかないかも。スレッド、ミューテックスロック、チャネル、Erlangスタイルの並行処理、ナーサリー、非同期以外の何でもの方がずっと楽だな。これらは全部理解できるし、実際にそれらを使ってプロダクションシステムも作ったことがある。Zigが1.0に達したときには使えるようになってるといいな。今月初めに学び始めたけど、使うのがすごく楽しいよ。

22:06に笑いすぎて椅子から落ちそうになったよ :D

しばらくZigを触ってないな、Cの世界に留まってる。クリーンアップ属性（Cのための安価な「defer」）や、サニタイザー、静的解析ツール、ハードウェアレベルでのメモリ安全性のためのメモリタグ拡張（MTE）などがあって、Zig 1.0はまだ数年先だろうし、今の時代にZigに時間をかける強い理由って何だろう？再挑戦すべきか迷ってるんだ。

人々がasync IOを試すとき、いつも苦労してるように見える。例えば、Rustが所有権の背後にあるスタックベースのパラダイムを崩すから、そこでRustは死ぬんだ。以前は、aio Pythonでウェブサーバーのような小さなアプリを書くのが楽しかったけど、メッセージキューやウェブソケットが関わると特に面白かった。でも、普通の作業にはgunicornを使った方がいい。問題は、従来のasync I/Oソリューションはすべてシングルスレッドで、今の時代にデスクトップに16コアのマシンがあるのに、それは意味がない。チェスのゲームを始めるのに、キング以外の駒を全部捨てるようなもんだ。Javaや.NETのような流行遅れの言語は、質の高いマルチスレッドのランタイムを持ってるから、同時実行性と並列性を管理するための単一のパラダイムを提供してくれる。

Zigの方向性が混乱してる気がする。シンプルな言語を目指してるのか、複雑なものを目指してるのか？低レベルなのか高レベルなのか？この機能は、高レベルと低レベルの機能が奇妙に混ざっていて、かなり複雑だと思う。IOインターフェースはOOっぽいけど、リスコフの置換原則を破ってる。私にとって、これは関数の色問題を解決するものではなく、むしろ隠しているだけだ。IOインターフェースを持つ関数は、IOパラメータの入力との予期しない相互作用のために、ローカルで推論できない。特に、IOオブジェクトがライブラリの境界を越えて共有されるとき、これは特に厄介だ。内部コードとそのオブジェクトを共有する場合、ライブラリが内部でIOをどのように管理しているかを理解する必要がある。あるコンテキストで動作したコードが、別のコンテキストでは驚くほど動作しないこともある。ライブラリの作者として、期待通りに動作しないIOオブジェクトをどう扱うべきか？この問題を言語レベルで解決しようとするのは根本的に間違ってる気がする。IOのような広範なもののすべての潜在的な使用ケースを事前に予測することはできないから。だから、この方向性を探るべきでないとは言わないけど、もし私のプロジェクトなら、これを別のパッケージに分けて、標準とは呼ばないだろうな。

これは、他のほとんどの言語が使うasync/awaitの意味でのものではないことに注意する価値がある。別の言語では、コンパイラがasync関数を見ると、それを状態機械や「コルーチン」にコンパイルして、関数がawaitでマークされた指定されたポイントで自分自身を一時停止し、後で再開できるようにする。Zigでは、コンパイラはコルーチンをサポートしていたが、これが削除された。新しいデザインでは、asyncとawaitは単なる関数だ。デモで使われているスレッド実装では、awaitは操作が完了するまでスレッドをブロックするだけだ。公平を期すために、投稿の最後には、他に2つのIO実装が計画されていることが説明されている。一つは「スタックレスコルーチン」で、これは従来のasync/awaitに似ている。しかし、これまでの議論からすると、ちょっとバポーワーのように見える。 [1]で議論されたように、andrewrkは通常のasync/awaitキーワードを（再）追加するアイデアを明示的に拒否し、代わりに異なるデザインを望んでいる。23446の問題で追跡されている。しかし、23446の問題では、この機能がどのように機能するか、従来のasync/awaitをどのように改善するか、または関数の色付けをどのように回避するかについての合意がゼロのようだ。計画されているもう一つの実装は「スタックフルコルーチン」で、私が見た限りでは、これにはより計画があり、より有望だが、重要な未知数がある。このデザインの基礎は、グリーンスレッドやファイバーに似ている。低レベルのコード生成は、通常の同期コードと同じで、状態機械の変換はない。代わりに、ライブラリがネイティブのレジスタ状態とスタックを入れ替えることで一時停止を実装する。これは、OSスレッド間の切り替え時にOSカーネルが行うことと同じだ。これ自体は、CのライブラリやGoのような言語のランタイムで以前に何度も実装されている。しかし、スタックをどれだけ割り当てるか分からないという重要な制限がある。事前にスタックを多く割り当てすぎると、OSスレッドとあまり変わらなくなるが、少なすぎるとスタックオーバーフローが簡単に発生する。Goは、必要に応じてスタックのチャンクを割り当てることでこれに対処しているが、それでもコストと動的割り当てへの依存が生じる。andrewrkは、代わりにコンパイラが関数とその呼び出し先が一時停止中に保存する必要がある状態の量に基づいて、必要なネイティブスタックの最大量を計算することを提案している。この場合、スタックはぴったり合うようにサイズを調整できる。ある意味、これはRustのasyncに似ていて、コンパイラがasync関数オブジェクトのサイズを計算する。Zigのアプローチは、asyncを特別扱いするのではなく、すべての関数呼び出しに適用される。その結果、利益はasyncコードのメモリ使用量を超えて広がる。コンパイラは、スタックオーバーフローがないことを静的に保証するので、この機能を使用するすべてのコードの信頼性が向上する。これは特に、通常、高い信頼性が求められ、利用可能なメモリが少ない組み込みシステムで役立つ。今、組み込みでは、GCCの機能（「-fstack-usage」）を使って、似たような計算を行うことがあるが、面倒すぎて人々はしばしば気にしない。だから、これをZigのファーストクラス機能にするのは素晴らしいことだと思う。でも、スタック使用量計算機が一般的でない理由がある。スタック使用量を静的に制限したいなら、まず再帰を禁止する必要がある。さもなければ、関数が再帰する回数を追跡するための何らかの言語メカニズムを追加しなければならない。再帰を禁止するのは、組み込みコードでは一般的だが、ほとんどのコードベースにはかなり面倒だ。再帰を追跡するのは確かに可能で、AgdaやCoqのような証明言語が再帰関数の終了を証明させることを示しているが、そういう言語には「普通の」言語にはない多くのツールがあるから、Zigでそのような機能がどれだけ使いやすいかは不明だ。この問題[2]では、どのように機能するかについて具体的な議論があまりない。次に、動的呼び出し（つまり、関数ポインタへの呼び出し）を禁止する必要がある。なぜなら、呼び出す関数が分からなければ、どれだけのスタックを使うか分からないからだ。これは、静的に知られている関数のセットのみを参照できる「制限された」関数ポインタ型を提案する[3]で、より具体的な設計の対象となっている。しかし、これがどれだけ使いやすく、組み合わせ可能かはまだわからない。少し引いて見ると、個人的には、Zigが他の言語と同じasync/await機能をコピーするのではなく、これらのことを試す意欲があるのは嬉しい。未開発の本当の可能性がある。逆に言うと、今日動作しているのは「async」と「await」が関数名に含まれているスレッドベースのI/Oライブラリだけなのに、勝利を主張するのは少し早いように思える。高性能な実装がどのように機能するかもわからないのに、I/Oライブラリのデザインを確定させるのは早すぎる気がする。とはいえ、スレッドI/Oでうまくいくアプリケーションも多いし、それを真剣な選択肢として受け入れる現代的なI/Oライブラリデザインを見るのは嬉しい。

うわ、例7はちょっと混乱するね。戻ってくる文字列がawaitとcancelの両方で得られる。これはzigの「隠れた制御フローなし」という原則に違反してる気がする。違反してないっていうのも分かるけど、やっぱり違反してる感じがする。でも、非同期コードでその原則の精神をどうやって保つのかは見当がつかないな。

個人的にはこれすごくクールだと思う。一つ気に入ってるのは、他の言語（例えばRoc）で見られる「プラットフォーム」概念が、Zigの「隠れた制御フローなし」というマントラに沿った形で固定されてること。結果的に、自分のコードがフックできる非POSIXのioを作るのが普通になるんだ。ゲームエンジンを書く？ユーザーがスクリプトに注入した効果的な関数のセットとやり取りできるようにするんだ。プラットフォームライター（ゲームエンジンのような）として、基本的にサンドボックスを作ることができる。欠けている部分は、任意のextern C関数を呼び出すアクセスを制御することかも。もしかしたら、その能力はioによって提供されて、呼び出すコードが何をするかについての確実な保証を作る必要があるかもしれない。（デバッグプリントは別の制御されていない効果だね。）