コルーチンは決して去りませんでしたが、その間、他の物に隠れていました。非同期プログラミングへの最近の関心の高まり、したがってコルーチンは、主に3つの要因によるものです。関数型プログラミング手法の受け入れの増加、真の並列処理（JavaScript！Python！）のサポートが不十分なツールセット、そして最も重要なこと：スレッドとコルーチン間のトレードオフの違いです。一部のユースケースでは、コルーチンは客観的に優れています。
80年代、90年代、そして今日の最大のプログラミングパラダイムの1つはOOPです。OOPの歴史、特にSimula言語の開発を見ると、クラスがコルーチンから進化したことがわかります。Simulaは、離散イベントを含むシステムのシミュレーションを目的としていました。システムの各要素は、1つのシミュレーションステップの期間中にイベントに応じて実行され、他のプロセスに作業を任せるための処理を行う個別のプロセスでした。Simula 67の開発中に、クラスコンセプトが導入されました。これで、コルーチンの永続的な状態がオブジェクトメンバーに保存され、メソッドを呼び出すことでイベントがトリガーされます。詳細については、Nygaard＆Dahl の論文「SIMULA言語の開発」を読んでください。
面白いことに、私たちはずっとコルーチンを使用してきましたが、単にそれらをオブジェクトと呼び、イベント駆動型プログラミングと呼んでいました。
並列処理に関しては、2種類の言語があります。適切なメモリモデルを持つ言語とそうでない言語です。メモリモデルでは、「変数に書き込み、その後別のスレッドでその変数から読み取った場合、古い値、新しい値、または無効な値が表示されますか？「前」と「後」とはどういう意味ですか？どの操作がアトミックであることが保証されていますか？」
適切なメモリモデルを作成することは困難であるため、これらの不特定の実装定義の動的オープンソース言語（Perl、JavaScript、Python、Ruby、PHP）のほとんどについては、この取り組みが行われたことはありません。もちろん、これらの言語はすべて、元々構築されていた「スクリプト」をはるかに超えて進化しました。まあ、これらの言語のいくつかは何らかの種類のメモリモデルドキュメントを持っていますが、それらは十分ではありません。代わりに、ハッキングがあります：
Perlはスレッド化サポート付きでコンパイルできますが、各スレッドには完全なインタープリター状態の個別のクローンが含まれているため、スレッドが非常に高価になります。唯一の利点として、このシェアードナッシングアプローチはデータの競合を回避し、プログラマがキュー/信号/ IPCを介してのみ通信するようにします。Perlには非同期処理に関する強力なストーリーはありません。
JavaScriptは常に機能プログラミングを豊富にサポートしてきたため、プログラマーは非同期操作が必要なプログラムで継続/コールバックを手動でエンコードしていました。たとえば、Ajaxリクエストやアニメーションの遅延がある場合。Webは本質的に非同期であるため、多くの非同期JavaScriptコードがあり、これらすべてのコールバックを管理するのは非常に苦痛です。したがって、これらのコールバックをより適切に整理する（約束）、またはそれらを完全に排除するための多くの努力があります。
Pythonには、グローバルインタープリターロックと呼ばれるこの不幸な機能があります。基本的に、Pythonのメモリモデルは「並列性がないため、すべての効果が順番に表示されます。Pythonにはスレッドがありますが、これらはコルーチンと同じくらい強力です。[1] Pythonは、ジェネレーター関数を介して多くのコルーチンをエンコードできyieldます。適切に使用すれば、これだけでJavaScriptから知られるほとんどのコールバック地獄を回避できます。Python 3.5の最新のasync / awaitシステムは、Pythonで非同期イディオムをより便利にし、イベントループを統合します。
[1]：技術的には、これらの制限はPythonリファレンス実装であるCPythonにのみ適用されます。Jythonのような他の実装では、並列に実行できる実際のスレッドを提供していますが、同等の動作を実装するにはかなりの時間をかけなければなりません。基本的に、すべての変数またはオブジェクトメンバは揮発性変数であるため、すべての変更はアトミックであり、すべてのスレッドですぐに表示されます。もちろん、揮発性変数を使用することは、通常の変数を使用するよりもはるかに高価です。
RubyとPHPを適切にローストするのに十分な知識がありません。
要約すると、これらの言語の一部には、マルチスレッドを望ましくないまたは不可能にする基本的な設計上の決定事項があり、コルーチンなどの代替手段や非同期プログラミングをより便利にする方法に重点が置かれています。
最後に、コルーチンとスレッドの違いについて話しましょう。
スレッドは基本的にプロセスに似ていますが、プロセス内の複数のスレッドがメモリ空間を共有する点が異なります。これは、スレッドがメモリに関して決して「軽量」ではないことを意味します。スレッドは、オペレーティングシステムによってプリエンプティブにスケジュールされます。これは、タスクスイッチのオーバーヘッドが大きく、都合の悪いときに発生する可能性があることを意味します。このオーバーヘッドには2つの要素があります。スレッドの状態を中断するコストと、ユーザーモード（スレッドの場合）とカーネルモード（スケジューラーの場合）を切り替えるコストです。
プロセスが独自のスレッドを直接かつ協調的にスケジュールする場合、カーネルモードへのコンテキスト切り替えは不要であり、タスクの切り替えは間接関数呼び出しに比べてかなり高価です。これらの軽量スレッドは、さまざまな詳細に応じて、グリーンスレッド、ファイバー、またはコルーチンと呼ばれる場合があります。グリーンスレッド/ファイバーの注目すべきユーザーは、初期のJava実装であり、最近ではGolangのGoroutinesでした。コルーチンの概念的な利点は、コルーチン間で明示的に行き来する制御フローの観点から実行を理解できることです。ただし、これらのコルーチンは、複数のOSスレッド間でスケジュールされない限り、真の並列処理を実現しません。
安価なコルーチンはどこで役立ちますか？ほとんどのソフトウェアには膨大な数のスレッドが必要ないため、通常の高価なスレッドでも大丈夫です。ただし、非同期プログラミングはコードを単純化する場合があります。自由に使用するには、この抽象化が十分に安価でなければなりません。
そして、ウェブがあります。上記のように、ウェブは本質的に非同期です。ネットワーク要求には、単に長い時間がかかります。多くのWebサーバーは、ワーカースレッドでいっぱいのスレッドプールを維持しています。ただし、これらのスレッドは、リソースを待機しているため、ディスクからファイルを読み込むときにI / Oイベントを待機している、クライアントが応答の一部を確認するまで待機している、またはデータベースが待機するまで、ほとんどの時間アイドル状態になりますクエリが完了します。NodeJSは、結果として生じるイベントベースの非同期サーバー設計が非常にうまく機能することを驚異的に実証しました。明らかにJavaScriptはWebアプリケーションに使用される唯一の言語とは程遠いため、非同期Webプログラミングを容易にする他の言語（PythonおよびC＃で顕著）にも大きなインセンティブがあります。