論文をリンクするんじゃなくて、もうちょっと詳しく説明してくれない？ 定義はまあまあ良いと思ったけど。 > 非同期性：タスクが順不同で実行されても正しい可能性。 > 同時実行性：システムが複数のタスクを同時に進行させる能力、並列性やタスクの切り替えを通じて。 > 並列性：システムが物理レベルで複数のタスクを同時に実行する能力。

だから、僕はこの用語を完全に使うのをやめたんだ。話す相手みんなが違う理解をしてる気がするし、コミュニケーションに全く役立たなくなった。

著者は、自分がブログ記事で使っている用語の定義が存在することを理解している。彼は改訂された定義を提案しているんだ。新しい定義が正確であれば、問題ないと思う。それを採用するかどうかは読者次第だね。

ランポートの論文の半分の概念をほとんどの言語で表現できないことを忘れないで。スレッドを開始するときに、全体的な時計の順序や部分的な時計の順序について話すことはないよね。プロトコルを設計する時にTLA+でしかやらない。とはいえ、「Zigには非同期APIに、非同時実行で実行するとコンパイルエラーを投げる関数がある。Zigはそれを言わせてくれる」という新しい用語を表現する必要はないと思う。それを新しい理論を提案せずにやるのは全然問題ないよ。

このアプローチを「妥協なし」と呼ぶのはかなり勇気がいることだと思う。まだ実際には試されていないからね。君の言う通りだ。とはいえ、「Jai」が成功しているとされるものにかなり近いように見える（暗黙のIOコンテキストを使っているけど、明示的に渡されるものではない）。でも、それを実際に試されていると言えるかどうかは議論の余地があるよね…

コードはかなり防御的で、基本的には最も並行・同時実行のIOバージョンを使うことを前提にしなければならないと思う。まさにその通りだけど、なぜ誰もが異なる考えを持つと思うのか、同期と非同期の実行の両方をサポートすることが目標なのに？でも、非同期性がIOイベントハンドラーの低レベルでうまく行われていれば、どこでもこれらの原則に従って簡単に実装できるはずだよ。最悪でもコードが逐次実行される（つまり遅くなる）だけで、レースやデッドロックにはならないはず。

純粋な1対1の並列性は、yieldを伴わない同時実行の一形態としてカウントするよ。でも、それ以外は、すべての非並列同時実行は、たとえそれが命令レベルであっても、何らかのリズムで実行をyieldしなければならないに同意する。 （例えば、CUDAでは、ワープ内の分岐するスレッドが命令の実行をインターリーブするので、一方の分岐が他方でブロックしようとする場合がある。）

著者は、単に同時実行の定義から実行の譲渡という概念を引っ張り出して、この新しい「非同期」という用語に持ち込んだだけだと思う。記事には正反対のことが書いてあるけどね。>（そしてタスクスイッチングは、上で述べた定義によれば、同時実行特有の概念です）

同時実行は譲渡を意味しないよ… 同期ロジックは何らかの同期を含むし、譲渡は同期の一つの方法かもしれない。それが君の言いたいことだと思う。非同期ロジックは、同期や譲渡なしで同時実行を実現してる。実際のところ、同時実行と非同期ロジックはフォン・ノイマンマシンには存在しないんだよね。

完全に同意します。投稿のサーバー/クライアントの例は、進行できないプログラムの一例に過ぎませんが、あなたが挙げた別の例は同じ方法では解決できないもので、時間が経つにつれて発見される例はもっとたくさんあると思います。私の意見では、非同期を使用する場合は同時実行性を確保する必要があります。

厳密に言えば、可換性は（2項）演算に対して定義されているから、もし2つの非同期文（例えば接続/受け入れ）が可換だと言うなら、「どの演算の下で？」と尋ねざるを得ない。今のところ、私のベストな答えはバインド（>>=）演算子（偶然にもそのインスタンスの一つである.then(...)を含む）だけど、これはあくまで曖昧な直感に過ぎない。

可換性は、片方が完全に前か後ろにあるという点で、ずっと弱い主張だよ。例えばABはCと可換かもしれないけど、ABC=CABとは限らない。非同期の場合、ABC=ACB=CABが保証されるんだよね。（これに対する既存の数学用語があるかもしれないけど、私は知らない）

「非同期」という言葉はこの概念にはあまり良くないし、実際には非常に明確に定義された数学的な言葉がある：可換性。別の用語がこの概念を定義しているからといって、それがより良い言葉だとは思わない。「可換性」は、私の意見では、混乱しているように感じるし、聞こえるし、読むのも難しい。非同期の方がずっと受け入れやすいよ。

非同期性は部分的な順序付けも可能にします。二つの操作は特定の順序で終了する必要があるかもしれませんが、その順序で実行する必要はありません。例えば、引き算は可換ではありません。でも、残高と控除を二つの別々のクエリとして計算し、その結果を適切な順序で適用することができます。

書かれている通り、asyncConcurrent(...)はめちゃくちゃ混乱するし、このブログ記事を暗記しない限り、このコードが何を意味するのか全く分からないよ。Zigが新しいヒップスター的なことを色々試してるのは分かるけど、半分の時間はただ直感的じゃなくて混乱させるだけだよね。何とかして（Rustのライフタイムみたいに）非同期ベースの可換性や操作の順序を実装するか、もうみんなが慣れているものを使った方がいいと思う。賛成できないな。混乱するのは、ブログ記事を覚えておかないといけないからで、核心的なアイデアを内面化してしまえば全く混乱しないはず。問題は、アイデアを内面化する価値があるのかってことだよね。分からないけど、確実に内面化する人もいて、これを念頭に置いて色々やろうとする人もいるだろうし、しばらくしたらこの道がどこに繋がるのか見えてくると思う。その時に良いアイデアかどうか判断できるようになるはず。 > 「非同期性」はこの文脈では非常に悪い言葉で、数学的には「可換性」という非常に明確な用語がある。これに「可換性」を使うのはリスクがある。Zigには演算子があって、その中には可換なものもある。だから混乱すると思う。例えば、f() + g()と書いたら、加算は可換だからZigはf()とg()を並行して実行することができる。実行順序と可換性は別のことだよね。おそらく、可換演算子と非可換演算子を一つのものにまとめることもできるかもしれないけど、それが良いアイデアかどうかは分からないし、これは非同期性を実験するのとは全く別の問題だと思う。

通常、コード内の操作の順序は行番号で示されます。ループを除いて、ループは後ろに戻ることを許可し、一時的に他の局所的な線形操作にジャンプすることを許可する手続きがあります。非前向きなことをするための構文はたくさんあります。

一部の操作は可換です（順序は重要ではない：加算、乗算など）。面白い事実：加算においては順序が重要です。（広く異なる指数を持つ多くの浮動小数点数を加算する場合。）

そうだな、俺の直感では、これを達成するには（ゾッとするけど）.then(...)のパラダイムの方がいいと思う。最悪だけど、知らない悪魔より知ってる悪魔の方がマシだよ。awaitの全体的なアイデアは、.then()の醜さなしに古い直感を使えるようにすることなんだ。f(); await g(); h()は、期待通りの実行順序になってる。

確かにこれは最も一般的な使い方だけど、反例としてRust（またはC#、F#、OCaml 5+）を挙げるよ。これらはOSスレッドと非同期の両方をサポートしてる。OSスレッドはCPUバウンドなタスクに向いてて、非同期はI/Oバウンドなタスクに向いてる。非同期（またはGoスタイルのM:Nスケジューリング）の主な利点は、RAMがあれば、好きなだけタスクやファイバー、ゴルーチンを立ち上げられることだよ。OSスレッドを使う場合は、コンテキストスイッチでCPUが詰まらないようにレスポンシブにプールする必要がある。これは難しくはないけど、I/O以上のことをやると、面白いデッドロックに遭遇することがある。

俺はこの件に詳しくないけど、こう答えるかな：非同期コードは、ブロッキングだったコードを非ブロッキングにすることで、他のことが進行中でも完了できるようにするものだよ。俺は埋め込みループでよく作業するから、長時間ブロッキングするコードがI/Oを壊したり、目に見える/聞こえるドロップアウトを引き起こすことがあるから、これが明らかな答えだと思う。

俺にとって重要なのは、非同期性の抽象的な概念とそれがどう実装されるかを区別することだよ。後者はプログラミング言語の抽象レベルと、マシン内の技術的な調整手段の両方を指してる。最高レベルの抽象概念としては、単に同期の二重性だね。つまり、何らかの形で一緒に作業する必要がある二者（またはそれ以上）が同期していない状態を意味する。何かが終わった後に何が起こるかが分からない、または定義されていないということだ。そう考えると、この定義は難しくない。難しいのは、言語で設計された抽象的手段だ。理解したり、間違いなく使ったりするために必要な認知的努力の量だよ。

非同期を定義する必要があるのかもよくわからない。難しいし（実際そうだし）、一つのことに合わせることができないからね。問題は、「非同期」を定義することが役に立つのか？それともイベントループ？物理チップの領域には、真の並列処理を可能にする概念がたくさんあるはずだし、「ユーザーの指」や「クイックジョブ」、ジョブキューやブロッキング・ノンブロッキングAPIには全然問題ないよ。指はタッチイベントやマウスクリック、キーボードや一般的なユーザーの発動イベントを象徴していて、これをクイックジョブに合わせる必要がある。クイックジョブはすごく小さい（実行時間的に）ブロッキングなジョブで、ブラウザによってキューに入れられて目標に達するために使われる。ノンブロッキングAPIが好きなのは、時間のかかるジョブを基盤に任せて、やりたいこと（データをインデックスDBに保存する）に対してクイックジョブを書くだけで済むから。成功した場合や失敗した場合に何が起こるか（異なるクイックジョブ）も考えなきゃいけない。同期や非同期はあまり助けにならないけど、もちろん他の人がそれについて話すときや、自分が使うとき（あるいは自分の好きなAIコーダーが）非同期を見たりするのは理解しなきゃいけない。でも、結局ノンブロッキングAPIを意味するだけなんだよね。ただ、非同期プログラミングモデルは実際にはすごくブロッキングなクイックジョブを書くことになっていて、ノンブロッキングな性質はブロッキングジョブの小さくて原子的な性質（実行時間的に）にある。これを混沌とした非決定的なイベントに合わせようとしてる。指やブラウザ、その他のものでトリガーされるイベントにね。正直言うと、これは混乱してるけど同時に天才的だと思う。非同期やそのモデルを理解するのは本当に難しかった。これが何かを意味するとは思えないんだ。実際、イベント、ブロッキングジョブ、ジョブキュー、ノンブロッキングAPIのような異なる概念を使えば理解するのはとても簡単なんだけど。私たちが何をしているのか、他の人が何をしているのか（ブラウザのコードやOSなど）を知ることも重要だと思う。C++のコードがスレッドで並行モデルを宣言するのと似ていて、OSが決定するんだ。JSでは、ノンブロッキングAPIを使っていて、これは暗黙的におそらく並行モデルを宣言している。ブラウザやNodeなどがそれを使うべきだし、彼らはいつもそうしてると思う。一番大事なのは、ジョブを素早く、たぶん30-50ms以内に保つこと。ノンブロッキングAPIは素晴らしいから、ジョブは意図を宣言するだけで終わる。C++やRustのような言語は、実際のタスクを並行に実行したいことをOSに宣言するから、たとえOSに実際の物理スレッドが1つしかなくても、UIは応答性がある。なぜなら、OSがUIコードの実行と「実際のタスク」の実行（ネットワークやデータベースなど）を切り替えるから。だから、非同期プログラマーがやるべきことは、素晴らしいUXモデルを作って、イベントをクイックジョブに合わせることだよ。

それは共感できるね。非同期やマルチスレッドコードのすべての可能なインタリーブをテストするのは、悪名高く難しい。高度なファジングツールや同時実行テストフレームワークを使っても、苦痛のある本番からの学びなしには完全な自信を得ることはめったにない。分散システムでは、さらに悪化するよ。例えば、Webhook配信インフラを設計する際には、サービス内の非同期コードだけでなく、ネットワークのリトライやタイムアウト、システム間の部分的な失敗にも対処しなければならない。信頼性の高いWebhookパイプラインを構築する際にこれに直面したことがある。リトライ、重複排除、高い同時実行性の下での冪等性を確保することが、完全なエンジニアリングの問題になったんだ。だから、多くのチームは今、Vartiq.comのような専門サービスにこれをオフロードしている。ここで働いているけど、これは自動リトライと可観測性を備えた保証されたWebhook配信を扱っている。これによって、自分のコード内の非同期テストの問題は解消されないけど、運用の同時実行性の複雑さを一部抽象化することで影響範囲を減らしている。完全に同意するよ – 非同期、スレッド、分散同時実行はお互いのリスクを増幅させる。コミュニケーションとシステム設計の注意が、どんな構文やライブラリの選択よりも重要だね。

Zigでは、テスト用のIo実装を用意する予定で、これはファジングを使って並行実行モデルの下でコードをストレステストする可能性があるよ。とはいえ、重要な洞察は、ほとんどのライブラリコードがio.asyncやio.asyncConcurrentを呼び出さないと期待していることだ。例えば、ほとんどのデータベースライブラリはこれを必要とせず、シンプルな同期コードを含むことになる。でも、そのコードはアプリケーション開発者がより高いレベルで非同期性を表現するために使えるようになる：io.async(writeToDb)やio.async(doOtherThing)。これによって、非同期/awaitがあちこちに散らばっているよりも、エラーが起こりにくく、理解しやすくなるよ。

パラレルタスクはシェーダーみたいなもんだよ。同じタスクを物理レイヤーで同時にたくさん実行してる感じ。それが「シングルインストラクションマルチプルデータ」ってやつで、これは別の問題だと思う。パラレル処理のいい例はFPGAだね。全てのゲートが同時に切り替わってるから、実際に全体を同期させる方法を考えないと、何も役に立たないものができないよ。* PLLは別として。