据我了解 libgreen is not a part of Rust standard library 了。我也找不到单独的 libgreen 包。有一些替代方案 - coroutine，目前不提供实际的绿色线程，以及 green-rs，它已损坏。我是否正确理解，目前 Rust 中没有类似 Go 的轻量级进程？
【问题讨论】：
std（或主发行版的其余部分）中没有轻量级任务库，green 无法编译，coroutine 似乎还没有完全处理线程方面，这是正确的.我不知道这个空间有任何其他图书馆。
至于发生了什么：与该问题相关的 RFC —RFC 230 — 是规范的信息来源。总结是发现处理绿色线程/IO 的方法（std 试图在两个模型之间进行抽象，允许它们自动互操作地使用）是不值得的缺点。现在，std 旨在提供有用支持的最低基线：对于 IO/线程，这意味着操作系统功能的“精简”、安全包装器。
【讨论】：
阅读此https://aturon.github.io/blog/2016/08/11/futures/ 以及：
Steve Klabnik's response 在 cmets 中：
一开始，Rust 只有绿色线程。最终，它是 决定没有系统线程的系统语言是......奇怪。 所以我们需要添加它们。为什么不添加选择？由于接口 可能是一样的，为什么不抽象它们，你可以 选择你想要的？
同时，默认情况下绿色线程的问题是 成为问题。分段堆栈导致缓慢的 C 互操作。你需要一个 运行时来管理它们等。此外，整体抽象是 造成不可接受的成本。绿线不是很绿。 此外，由于需要在某天迫在眉睫，决策 需要权衡取舍。而且由于 Rust 应该 是一种系统语言，具有 1:1 线程并且基本上没有运行时 比 N:M 线程和运行时更有意义。 .所以 libgreen 是 移除后，界面被重新设计为以 1:1 线程为中心。
“有朝一日即将发布”是其中的重要组成部分。我们想成为 使用 Rust 非常稳定，并且所有要做的事情实际上 发布 1.0，我们不想具体化我们没有的界面 高兴。哎呀，我们提取了很多甚至更少的库 出于类似的原因很重要，例如 rand。工程就是一切 权衡，我们决定选择极简主义。
mio 对我们来说是一个非入门者，就像大多数其他用于 Rust 的异步 i/o 框架一样，因为我们需要 Windows，而且我们不想要 被锁定在一个昂贵的更换图书馆中，这可能会得到 孤儿。
在这里完全理解，尤其是在一般情况下。在里面 在特定情况下，mio 要么支持 Windows，要么支持 将发布特定于 windows 的 mio 版本，其中包含 为所有平台提供功能的更高级别的包。而在 这种情况下，它由当前正在使用的人之一维护 在生产中严重生锈，所以它不太可能随时消失 很快。但是，除非你积极参与，否则很难知道事情 像那样，这本身就是一个问题。
我们愿意移除 libgreen 的原因之一是您 可以编写自己的库来执行不同类型的 IO。 1.0 是一个 强大的核心，我们对永远稳定感到满意，而不是最终 少量。像https://github.com/carllerche/mio 这样的库可以测试 处理异步 IO 等事情的不同方式，以及当它们 足够成熟，我们可以随时将它们拉回到标准库中，如果 需要。但与此同时，您的 Cargo.toml 只需一行 添加它们。
还有这样的text from reddit:
不幸的是，他们最终取消了 greenlet 支持，因为 他们的比内核线程慢，这反过来证明了 有人不明白如何让语言编译器生成 有效的无堆栈协程（不足为奇， 这个世界上正确接线的工程师并不多，但请看 http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/ 了解更多详情）。因为 libuv 是 “慢”（这只是因为它只是单线程的，加上 强制每个异步操作使用 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，一个实现类似于 goroutine 的绿色线程的 crate。
【讨论】：