libgreenはどうなりましたか？
私が理解している限りlibgreen Rust標準ライブラリ の一部ではありません。また、別のlibgreenパッケージを見つけることができません。いくつかの選択肢があります-- coroutine 、これは実際には緑色のスレッドを提供しません、そして green-rs は壊れています。今のところ、軽量のGoのようなプロセスはないことを理解していますか？さび？
あなたは正しいです。std（またはその他のメインディストリビューション）には軽量タスクライブラリがなく、greenはコンパイルされず、coroutineはそうではないようです。スレッド処理を完全に処理します。このスペースの他のライブラリについては知りません。
何が起こったかに関しては、その問題によってリンクされているRFC -- RFC 2 —は、正規の情報源です。まとめは、グリーンスレッディング/ IOを処理する方法（stdが両方のモデルで抽象化を試み、それらを自動的に相互運用的に使用できるようにする）には不利な点はないことがわかりました。現在、stdは、有用なサポートの最小限のベースラインを提供することを目的としています。IO/スレッディングでは、オペレーティングシステム機能の「薄く」安全なラッパーを意味します。
これを読んでください https://aturon.github.io/blog/2016/08/11/futures/ そしてまた：
Steve Klabnikの応答 コメント内：
最初はRustには緑色のスレッドしかありませんでした。最終的に、システムスレッドのないシステム言語は奇妙であると判断されました。それで、それらを追加する必要がありました。選択肢を追加しないのはなぜですか？インターフェースは同じであるかもしれませんが、それらを抽象化しないのはなぜですか、そしてあなたはあなたが望むものを選ぶことができますか？
同時に、デフォルトでグリーンスレッドの問題が問題になりつつありました。セグメント化されたスタックにより、Cの相互運用が遅くなります。それらを管理するためのランタイムなどが必要です。さらに、全体的な抽象化は許容できないコストを引き起こしていました。緑の糸はあまり緑ではありませんでした。さらに、いつか迫り来るリリースを実際に行う必要があるため、トレードオフに関して決定を下す必要がありました。そしてRustはシステム言語であると想定されているため、1：1スレッドを持ち、基本的にランタイムがないのはN：Mスレッドとランタイムよりも理にかなっています。したがって、libgreenが削除され、インターフェイスは1：1のスレッド中心になるようにやり直しました。
「いつか迫り来るリリース」はその大部分を占めています。私たちはRustで本当に安定したいと思っています。実際に1.0を出荷するためにすべきことはすべて、満足できないインターフェースを具体化したくありませんでした。 Randのように、同様の理由でそれほど重要ではないライブラリをたくさん引き出しました。エンジニアリングはすべてトレードオフに関するものであり、ミニマリズムを選択することにしました。
mioは、Rustの他の非同期I/Oフレームワークのほとんどと同様に、私たちにとっては初心者ではありません。Windowsが必要であり、また、孤立する可能性のある高価なライブラリに取り替えたくないからです。
ここでは、特に一般的なケースで完全に理解されています。特定のケースでは、mioがWindowsをサポートするか、Windows固有のバージョンのmioがリリースされ、すべてのプラットフォームに機能を提供する上位レベルのパッケージが提供されます。この場合、現在Rustを本番環境で頻繁に使用している人が保守しているため、すぐになくなることはありません。ただし、積極的に関与している場合を除き、そのようなことを知ること、それ自体が問題です。
Libgreenを削除することに抵抗がなかった理由の1つは、独自のライブラリを作成してさまざまな種類のIOを実行できることです。 1.0は、最後のビットではなく、私たちが永遠に安定させることについて良いと思う強力なコアです。 https://github.com/carllerche/mio のようなライブラリは、非同期IOなどを処理するさまざまな方法をテストでき、十分に成熟している場合は、常に標準に戻すことができます必要に応じてライブラリ。しかし、当面は、Cargo.tomlに1行追加するだけです。
そして、そのような redditからのテキスト ：
残念ながら、それらはカーネルスレッドよりも遅いため、グリーンレットサポートを缶詰にしてしまいました。これは、言語コンパイラにスタックレスコルーチンを効果的に生成させる方法を誰かが理解していないことを示しています（当然のことながら、正しい方法で配線されたエンジニアの数は多くありません。この世界では、しかし http://www.reddit.com/r/Rust/comments/2l0a4b/do_Rust_web_servers_use_libuv_through_libgreen_or/ を参照してください）。そして、それらはlibuvが「遅い」ために非同期I/Oを固定しました（これはシングルスレッドのみであるためであり、さらに、バッファーが完了するまで継続する必要があるため、非同期操作ごとにmalloc + freeを強制します。同期I/O参照 http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html ）これは本当に残念だった-彼らはlibuvをより良いもので置き換える機会を得るべきでした（ヒント：ASIO + AFIO、そうです、私は両方ともC++であることを知っていますが、Rustは現在のどれよりもはるかに優れたC++相互運用でそれを行うことができます現在のところ）C++からの驚くべきステップである可能性のあるものの中で常に非同期のすべてを缶詰にする代わりに、Erlangの欠点のないErlangのほとんどの利点があります。
初心者向けに、ゴルーチンに似たグリーンスレッドを実装するクレート may が追加されました。