据我了解libgreen is not a part of Rust standard library了。另外，我找不到一个单独的libgreen包。有一些替代方案 - coroutine，它现在不提供实际的绿色线程，green-rs，它已被破坏。我是否理解现在在Rust中没有轻量级的Go-like进程？
答案 0 :(得分：19)
你是正确的std（或主要发行版的其余部分）中没有轻量级任务库，green无法编译，coroutine似乎没有完全处理线程方面。我不知道这个领域的任何其他图书馆。
至于发生了什么：由该问题链接的RFC - RFC 230 - 是规范的信息来源。总结是，发现处理绿色线程/ IO的方法（std试图在两个模型中进行抽象，允许它们自动地互操作）并不值得。现在，std旨在提供最低限度的有用支持基础：对于IO /线程，这意味着“瘦”，安全的操作系统功能包装。
答案 1 :(得分：15)
阅读此https://aturon.github.io/blog/2016/08/11/futures/以及：
评论中的一开始，Rust只有绿线。最终，它是 决定没有系统线程的系统语言是......奇怪的。 所以我们需要添加它们。为什么不添加选择？自接口 可能是一样的，为什么不抽象它们，你可以 选择你想要的那个？
同时，默认情况下绿线的问题是 成为问题。分段堆栈导致慢速C互操作。你需要一个 运行时来管理它们等等。此外，整体抽象是 造成不可接受的费用。绿色线程不是很绿。 此外，需要实际释放某一天迫近的决定 需要在权衡方面做出贡献。因为Rust应该是 是一种系统语言，拥有1：1的线程，基本上没有运行时 比N：M线程和运行时更有意义。 。所以libgreen是 删除后，界面重新完成为1：1线程中心。
有一天即将发布＆＃39;是它的重要组成部分。我们想成为 Rust真的非常稳定，并且实际上还有很多事情要做 发货1.0，我们并不想结晶我们没有的界面 高兴。哎呀，我们掏出了很多甚至更少的图书馆 因为类似的原因很重要，比如兰特。工程就是这样 权衡，我们决定选择极简主义。
对于我们来说，mio对我们来说是一个不起作用，因为我们需要Windows而且我们不想要Windows，因此大多数其他async的异步i / o框架都是如此。 锁定一个昂贵的替换库可能会得到 孤立。这里完全理解，特别是在一般情况下。在里面 具体情况，mio要么有Windows支持，要么有 特定于Windows的mio版本即将发布，带有 更高级别的包，为所有平台提供功能。并在 在这种情况下，它由当前正在使用的人之一维护 在生产中大量生锈，所以它不可能随时消失 不久。但是，除非你积极参与，否则很难知道事情 像这样，这本身就是一个问题。
我们很乐意删除libgreen的原因之一就是你 可以编写自己的库来执行不同类型的IO。 1.0是一个 强大的核心，我们感觉永远稳定，而不是决赛 位。像https://github.com/carllerche/mio这样的图书馆可以测试出来 处理async IO之类的东西的不同方式，以及它们的处理方式 如果成熟的话，我们可以随时将它们拉回标准库中 需要。但与此同时，它只是你Cargo.toml的一条线 将它们添加进去。
这样的text from reddit：
不幸的是，他们最终获得了支持greenlet的支持 他们比内核线程慢，后者反过来证明 有人不明白如何让语言编译器生成 无堆叠协程有效（不奇怪，数量 工程师有正确的方式在这个世界上并不多，但是看看 http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/ 更多细节）。他们将异步i / o封装起来，因为libuv是 “慢”（这只是因为它只是单线程，加上 强制malloc + free per async操作，因为缓冲区必须持续 直到完成，加上它对同步执行惩罚 我/见 http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html）， 这是一个真正的耻辱 - 他们应该抓住机会 用更好的东西取代libuv（提示：ASIO + AFIO，是的，我知道 它们都是C ++，但Rust可以用更好的C ++互操作来实现 目前没有它现在没有）而不是罐头 永远 - 异步 - 一切都可能是一个惊人的进步 从C ++开始，Erlang的大多数好处都没有缺点 Erlang。
答案 2 :(得分：5)
对于新手来说，现在有may，一个实现类似于goroutines的绿色线程的箱子。