プログラミングコミュニティでは、現代のプログラミング言語で広く採用されている async/await 機能について、熱い議論が交わされています。当初はコールバック地獄の解決策として称賛されたこの機能ですが、解決すべき問題以上の問題を生み出しているのではないかという議論が開発者の間で巻き起こっています。
関数の色付け問題
async/await に対する最も重要な批判の一つが、「関数の色付け問題」として知られる現象です。await を使用する関数は async として明示的にマークする必要があり、この要件はコールスタック全体に伝播していきます。この async マーカーの感染は、開発者にとって大きな課題となり、コードの複雑性を増大させる原因となっています。
代替アプローチ
代替案として、 Go 言語の並行処理アプローチが注目を集めています。 Go は async/await の代わりに、 goroutine とチャネルを使用し、CSP（Communicating Sequential Processes）として知られる方式を実装しています。このアプローチにより、開発者は同期的に見えるコードを書くことができ、実行時の並行処理の複雑さはランタイムが処理します。
CSP の方がシンプルです。シンプルな方が正しく実装しやすいのです。数十年前まで、私は C 言語で多くの非同期サーバーを書いていました。私にとっては簡単でしたが、多くの人々にとってはそうではありませんでした。今日では、より良い実装方法があります。
並行処理への主要なアプローチ：
- Async/Await ：明示的な非同期マーカーを持つスタックレスコルーチン
- Go 言語のアプローチ：暗黙的な並行性を持つスタックフルコルーチン
- CSP ：通信順次プロセス
- Virtual Threads ： JVM による軽量スレッドの実装手法
スタックフル・コルーチンの利点
多くの開発者は、 Go で実装されているようなスタックフル・コルーチンが、一般的な async/await 実装で使用されているスタックレス方式よりも優れた抽象化を提供すると主張しています。実行コンテキストの処理方法に主な違いがあり、 Go のアプローチでは、効率的な並行実行を維持しながら、非同期境界を明示的にマークする必要のないより直接的なコードを書くことができます。
UI プログラミングの課題
async/await を支持する重要な反論の一つが、UI プログラミングの分野から来ています。GUI アプリケーションでは、メインスレッドのブロックはインターフェースの応答性低下につながります。async/await は、UI の応答性を保ちながらバックグラウンド処理を扱う洗練された方法を提供します。これは特にフロントエンド開発やデスクトップアプリケーションで重要な価値を持っています。
パフォーマンスの問題
Java の仮想スレッドなどの最近の開発により、従来 async/await を正当化するために使用されてきたパフォーマンス面での議論に疑問が投げかけられています。一部の開発者は、特にコンテキストスイッチがボトルネックとなることが稀な一般的なビジネスアプリケーションにおいて、async/await がもたらす複雑さはそのパフォーマンス上の利点によって正当化されないと主張しています。
結論
async/await は多くの現代プログラミング言語の標準機能となっていますが、その価値をめぐる議論は続いています。この議論は、抽象化と複雑さの間、そして並行処理を扱う異なるアプローチ間の、ソフトウェア開発におけるより広範な緊張関係を浮き彫りにしています。この分野が発展するにつれて、これらの相反する懸念をより良くバランスさせる新しいパラダイムが登場するかもしれません。
参考文献：Async Await Is The Worst Thing To Happen To Programming