What happened to libgreen?

Question

As far as I understand libgreen is not a part of Rust standard library anymore. Also I can't find a separate libgreen package. There are a few alternatives - coroutine, which does not provide actual green threads for now, and green-rs, which is broken. Do I right understand that for now there is no lightweight Go-like processes in Rust?

Answer 1

You are correct that there's no lightweight tasking library in std (or the rest of the main distribution), that green doesn't compile and that coroutine doesn't seem to fully handle the threading aspect yet. I do not know of any other library in this space.

As for what happened: the RFC linked to by that issue—RFC 230—is the canonical source of information. The summary is that it was found that the method by which green threading/IO was handled (std tried to abstract across both models, allowing them to be used interoperably automagically) was not worth the downsides. Now, std aims to just provide a minimum base-line of useful support: for IO/threading, that means "thin", safe wrappers for operating system functionality.

Answer 2

Read this https://aturon.github.io/blog/2016/08/11/futures/ and also:

Steve Klabnik's response in the comments:

In the beginning, Rust had only green threads. Eventually, it was decided that a systems language without systems threads is... strange. So we needed to add them. Why not add choice? Since the interfaces could be the same, why not abstract over them, and you could just choose which one you wanted?

At the same time, the problems with green threads by default were becoming issues. Segmented stacks cause slow C interop. You need a runtime to manage them, etc. Furthermore, the overall abstraction was causing an unacceptable cost. The green threads weren't very green. Plus, with the need to actually release someday looming, decisions needed to be made regarding tradeoffs. And since Rust is supposed to be a systems language, having 1:1 threads and basically no runtime makes more sense than N:M threads and a runtime. . So libgreen was removed, the interface was re-done to be 1:1 thread centric.

---

The 'release someday looming' is a big part of it. We want to be really stable with Rust, and with all the things to do to actually ship a 1.0, we didn't want to crystallize an interface we weren't happy with. Heck, we pulled out a lot of libraries that are even less important for similar reasons, like rand. Engineering is all about tradeoffs, and we decided to choose minimalism.

mio is a non starter for us, as are most of the other async i/o frameworks for Rust, because we need Windows and besides we don't want to get locked into an expensive to replace library which may get orphaned.

Totally understood here, especially in the general case. In the specific case, mio is going to either have Windows support, or a windows-specific version of mio is going to be released, with a higher-level package providing the features for all platforms. And in this case, it's maintained by one of the people who's currently using Rust heavily in production, so it's not likely to go away anytime soon. But, unless you're actively involved, it's hard to know things like that, which is, of itself an issue.

One of the reasons we were comfortable removing libgreen is that you can write your own libraries to do different kinds of IO. 1.0 is a strong core that we feel good about stabilizing forever, not the final bit. Libraries like https://github.com/carllerche/mio can test out different ways of handling things like async IO, and, when they're mature enough, we can always pull them back in the standard library if need be. But in the meantime, it's just one line to your Cargo.toml to add them in.

And such text from reddit:

Unfortunately they ended up canning the greenlet support because theirs were slower than kernel threads which in turn demonstrates someone didn’t understand how to get a language compiler to generate stackless coroutines effectively (not surprising, the number of engineers wired the right way is not many in this world, but see http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/ for more detail). And they canned the async i/o because libuv is “slow” (which it is only because it is single threaded only, plus forces a malloc + free per async operation as the buffers must last until completion occurs, plus it enforces a penalty over synchronous i/o see http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html), which was a real shame - they should have taken the opportunity to replace libuv with something better (hint: ASIO + AFIO, and yes I know they are both C++, but Rust could do with much better C++ interop than the presently none it currently has) instead of canning always-async-everything in what could have been an amazing step up from C++ with most of the benefits of Erlang without the disadvantages of Erlang.

Answer 3

For newcomers, there is now may, a crate that implements green threads similar to goroutines.