Why did Rust remove the green-threading model; what's the disadvantage?

Question

Runtime freedom: Rust’s runtime system and green-threading model has been entirely removed, which cut the static binary size of “hello world” in half and has opened the door to lower-level hooks into the standard library. Implemented by Aaron Turon.

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

What's the disadvantage of the green-threading model?

Why is Erlang so fast?

Kusin

In Java they were slower than the native threads. (Though as I remember Erlang's BEAM VM uses green threads. So it seems to be fast-enough for their use cases.) – Junta

@GáborBakos Early JVMs had 1:N green threading, i.e., there was only one OS thread which runs all N Java threads. Naturally this cannot benefit from multi-core CPUs. Both Erlang, older Rust, and also Go use N:M threading, where N OS threads cooperate to run M green threads. – Epoch

An interesting paper about green threads in rust which discusses some of the considerations behind a potential implementation: stanford-cs242.github.io/f17/assets/projects/2017/kedero.pdf – Rodgers

Answer 1

Erlang uses green threads with preemption. This is possible only because Erlang has a VM, which also allows a lot of other things like code hotswap. But languages with VM are unsuitable for systems programming because they always have some constant overhead, both in memory and processing power. Rust is a systems programming language, and so it cannot have a significant runtime system. I'd also add that Erlang is not fast. It is notoriously ineffective in numerical computations, for example - see here. Its concurrency model allows for high throughput for I/O operations, but this is a different thing.

So in order to support green threads in a feasible way a language has to have some kind of runtime. The reasons of runtime removal in Rust are outlined in the corresponding RFC. In short, the runtime model used in Rust at that time was difficult to work with efficiently and hard to improve, while not having sufficient benefits due to implementation problems and general constraints due to the API, so it was scrapped. As far as I know, nothing in principle prevents someone from writing a green thread-based runtime for Rust, just no one did that yet.

Beige

Right, but we haven't greens in Rust yet, because some of Rust internals uses TLS and it's impossible to mutiplex greens on OS-threads like Go or Erlang does. We still have to work for solving it... – Triploid

There is may (github.com/Xudong-Huang/may) which is a green thread implementation. – Habana

@TerryShi I don't think it actually is a green threading library. It says "coroutines", which generally means 'cooperative' (as opposed to 'preemptive') multitasking, i.e. not thread-based – Eagleeyed

@Eagleeyed From my reading, the may library is in fact a green threading library. From the readme: It can be thought as the Rust version of the popular Goroutine. [...] Support schedule on a configurable number of threads for multi-core systems; – Maternal