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

acmerfight picture acmerfight · Apr 3, 2015 · Viewed 11.7k times · Source

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?

Answer

Vladimir Matveev picture Vladimir Matveev · Apr 3, 2015

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.