タイトルには同意。大げさすぎる。著者はトリビアルな関数のオーバーヘッドにこだわりすぎてる気がする。「パニック」と「リターン」の状態のオーバーヘッドが気になるみたいだけど、それほど大きな問題じゃないよ。ほとんどの有用な非同期ブロックは十分大きいから、エラーケースのオーバーヘッドは消えちゃう。インライン化が足りないって指摘には一理あるけど、大量のアクティビティを扱うときに制限されるのは、各アクティビティに必要な状態空間なんだよね。

タイトルについてだけど、これを選んだのはただの真実だから。2019年頃にasyncが導入されてから、あんまり変わってないよね。確かに、今はトレイトやクロージャでasyncが使えるようになったけど、それはタイプシステムの更新であって、asyncの仕組み自体の更新じゃない。ワーカーは少し扱いやすくなったけど、それもstd/coreの更新だし。私の理解では、async Rustを実現した人たちはかなり疲れてしまって、活動が減ってしまったみたいで、誰もそのバトンを引き継いでないんだ。（ただ、キャプチャされた変数のメモリ配置を最適化するGoogleの人たちからのPRが1つオープンになってるけど、これは本当にありがたい。）私や私の周りの人たちはヘビーユーザーだから、もしかしたら私がやるべきなのかも。子犬のように自由な感じかな。だから、タイトルはちょっと釣りっぽいけど、私はその背後に立ってるよ。

スレッドが正しいプログラミングモデルだった。 パフォーマンスやメモリにあまりこだわらない問題に関しては、そうだね。たぶん、デフォルトとしてスレッドを使うべきだよ。ただし、自分の問題がこの一般的な範疇に入らないと分かっている場合を除いてね。残念ながら、スレッドにはカーネルでの多くの管理オーバーヘッドがあって、コンテキストスイッチもかなり高コストだから、高パフォーマンスのシナリオではカーネルスレッドを使う余裕がないかもしれない。

スレッドは非同期+コールバックよりも良くも悪くもない。ただ違うだけ。スレッドにうまくマッピングできる問題もあれば、非同期で表現する方がずっと楽な問題もある。

スレッドが準備ができるまでスリープして、カーネルがそれを抽象化してくれる。 確かにそうだけど、カーネルとOSスケジューラを巻き込むと、物事は本来の速度よりも3〜4桁遅くなるんだ。最後にコルーチン/スケジューリングコードに取り組んでいたとき、即座に終了するスレッドを作成して参加させるのに約200μsかかって、私たちのグリーンスレッドを作成してスケジューリングし、待つのには約400nsかかった。誰かがまた別の非常に複雑な非同期フレームワークを設計するのを10年待つ必要はないよ。20行のASMで自分のグリーンスレッドやスタックフルコルーチンを作れるから。

問題は、両方の椅子に座ろうとすることから来てる。非同期を望むけど、オプトアウトしたいっていうのが、機能の色分けを含む多くの醜さを引き起こしてる。ゴーランを見てみて、すべてが非同期で、変更する方法がないのは素晴らしい。マイクロコントローラーのような、すべてのバイトが重要な場面にはあまり向いてないかもしれないけど、オーバーヘッドを許容できるなら、Rustの非同期よりずっと良い。非同期が導入される前は、Rustは面白くて合理的な言語だったけど、今は理由もなく目が痛くなるような混沌とした状態になっちゃった。

通常のコードはすでに非同期だったよ。非同期操作を待つ必要があるとき、スレッドは準備ができるまでスリープするし、カーネルがそれを抽象化してくれる。 あんまりそうじゃないと思う。非同期コードは、同時にできる処理を最大限に活かせてないことが多い気がする（例えば「N個のI/O操作を全部同時にやる」って書く代わりに「操作Xについて、await process(x)」って書く感じ）。でも、スレッドの世界ではこの同時実行の問題が悪化するんだよね。なぜなら、そんな同時実行に最適化する方法がないから。スレッドは本質的に重すぎて、効率的に同時実行を表現できないんだ。これは新しい教訓じゃなくて、ワークスティーリングエグゼキュータが従来のスレッドよりもずっと低いレイテンシーを提供することが知られてるのは長い間だし、これが理由でAppleはGCDを開発したんだよ。スレッドはカーネルに必要なワークロードに関する情報を提供しないし、カーネルスレッドは細かい同時実行を実現するための非常に重いメカニズムなんだ。しかも、I/Oや混合ワークロードの同時実行が必要なときはさらに厄介。すごく簡単に並列化できる純粋な計算とは違ってね。 すべてのプログラムがこのレベルのパフォーマンスを必要とするわけじゃない？多分、そうじゃないよ。でも、より高いパフォーマンスを達成するのはかなり簡単だし、実際には従来のアプローチでは同じ努力で達成できないレイテンシーやスループットを得られるんだ。非同期が方向的には正しいって言えるのは、io_uringがカーネルの高パフォーマンスI/Oへのアプローチで、従来のスレッドやシステムコールとは全然違うし、完了も非同期の同時実行に近いからだね（ただし、完全に活用するのは非同期の世界では難しいけど、async/awaitは非同期タスクの関係性を表現するには色が足りないからね）。

コールバックの方が実際には考えやすいと思う。並行処理をテストする時、レースコンディションを適切に処理できてるか確認するのが、コールバックだとスケジューリングをコントロールできるからずっと簡単なんだ。各コールバックは離散的な単位を表してるから、どのイベントが順序を入れ替えられるかがわかる。これで、いろんな順序を考慮しやすくなる。一方、スレッドだと順序を無視しがちで、別のスレッドで起こってるこの複雑さを考えないことが多い。簡単じゃなくて、単純すぎるんだよね。さらに、スケジューリングを変更したり、並行シナリオをテストするのは、スレッドを止めるための人工的な障壁を導入したり、I/Oをスタブ化してモックを渡してコールバックで順序を制御するようにしないとできない。コールバックの問題は、キャプチャされた時のコールスタックが論理的なコールスタックじゃないことが多いってこと。少数のライブラリやランタイムがコールスタックを意味のあるものにするために努力してる場合を除いてね。そうじゃなければ、良いエラーディフィニションが必要だよ。もちろん、パラダイムを混ぜて、両方の悪いところを持つこともできるけど。

私の理解では、「グリーンスレッド」も高コストなんだ。例えば、各「スレッド」に大きなスタックを割り当てる必要があるか、Goのようにスタックを動的に成長させるためにスタック割り当てをフックする必要がある。スタックを成長させると、移動させなきゃいけなくなって、スタックオブジェクトへのポインタを持てなくなるかもしれない。

現代の適切な言語は両方を提供してる。スレッドを維持しつつ、必要な時にだけasyncに手を伸ばせるんだ。選択肢を提供しない言語はまた別の問題だけどね。

この文脈でのカーネルって何？

組み込みではスレッドがないけど、同時待機を表現する方法が欲しいんだよね。全然違う問題だよ。

クラシックな関数の色付け問題。 https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

実際に何をしているかによるけど、シンプルな場合は型を置き換えてawaitするマクロを作れるかもしれないね。

キーワードジェネリクスに関する作業が進んでるみたいで、これによって関数がasyncやconstのようなキーワードに対してジェネリックになれるんだ。今のところ、両方の世界で生きるコードを書くためのベストな選択肢はsans-ioだね。Fireguardのトーマス・アイジンガーがこのパターンについて良い記事を書いてるよ。これによって同期/非同期の問題がうまく解決されるだけでなく、テストも簡単になって、DSTのような技術への扉も開かれる。私もこのトピックについて書いたことがあるけど、問題はasyncとsyncの違いだけじゃなくて、異なる実行環境によるものだってことを強調してる。0: https://github.com/rust-lang/effects-initiative 1: https://www.firezone.dev/blog/sans-io 2: https://notes.eatonphil.com/2024-08-20-deterministic-simulat... 3: https://hugotunius.se/2024/03/08/on-async-rust.html

こんにちは、著者です。ブログで、コンパイラの最もシンプルな最適化を2つすぐにハックしてみたことを書いたんだけど、実際の組み込み（非同期）コードベースで2%-5%のバイナリサイズの節約が得られたんだ。それに、デスクトップで行った簡単でおそらく深く欠陥のある合成ベンチマークでは、3%のパフォーマンス向上が見られた。だから、確かに重要なんだよ。最適化は積み重なることを忘れないで。LLVMが本来の動作をするのを妨げているからね。だから、未来のサイズを小さくすれば、LLVMがもっと最適化できるようになる。小さな変更が本当に大きな影響を与えるんだ。

C++ではそれをあまり感じられなかったし、他の分野でどうなってるのかも全然わからない。C++のISO委員会内でも、その言語の進化プロセスがちょっと壊れてるという合意があるみたいで、主にそのサイズと組織の仕方が原因なんだ。 > 唯一の不満は、目標の達成に特定の資金が必要で、ちょっとキックスターターっぽく感じることかな。これが今まで見つけた中で一番いいモデルなの？ 残念ながら、技術が商業的に普及するとこういう風になるみたい。大きな寄付者が興味のある部分だけを支援するのは責められないよね。幸い、TweedeGolfのかなりの資金は（オランダの）政府から来てると思う。

オープンソースには2種類の作業があると思う：1. 機能 2. メンテナンス 新しい機能は「売る」ことができる。作るのにお金がかかるけど、実際の問題を解決するからね。その問題もお金がかかるし、もしそれが機能を作るコストより高ければ、企業はお金を出すことに前向きだよね（一般的に）。メンテナンスは難しいけど、今はメンテナーファンドも出てきてる！ RustNLのやつみたいにね： https://rustnl.org/maintainers/ これらは広範な継続的な作業で、多くの団体が少しずつ支援してる。これが一番いいモデルかはわからないけど、少なくともなんとか機能してるみたい。

代替案は何だろう？tokioを使うのは全然嬉しいけど、他の人たちがsmolやasync-std、glommioとかの他のexecutorを楽しめるのもいいよね。tokioはしっかりメンテナンスされてるから、標準ライブラリの一部じゃなくても大丈夫だと思う。逆に、標準ライブラリに組み込んじゃうと、他のexecutorを使いにくくなったり、他のプラットフォームへの移植が難しくなったりするんじゃないかって心配してる。でも、もしかしたらその心配は杞憂かもね。

Javaの話が出たから言うけど、歴史を通じて似たような問題があったのは面白いよね。ログの件（今はslf4jに落ち着いてるけど、まだ他のライブラリを使ってるのも見かけるし）、commons（最初はApache Commons、今はGuava）、JSON（Jacksonに落ち着いたけど、GsonやSimple-jsonもよく見る）、nullabilityアノテーション（最初は非公式のJSR-305から始まって、次はchecker framework、最近はJSpecifyに移行してる）。こういう基本的なことは、言語が提供しないと、フラグメンテーションや準デファクトライブラリが出てきちゃうよね。