31

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?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
acmerfight
  • 745
  • 1
  • 7
  • 10
  • 1
    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.) – Gábor Bakos Apr 03 '15 at 08:08
  • 1
    @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. –  Apr 03 '15 at 10:38
  • An interesting paper about green threads in rust which discusses some of the considerations behind a potential implementation: https://stanford-cs242.github.io/f17/assets/projects/2017/kedero.pdf – tjb Jul 13 '21 at 09:09

1 Answers1

50

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.

Community
  • 1
  • 1
Vladimir Matveev
  • 120,085
  • 34
  • 287
  • 296
  • 5
    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... – DenisKolodin Nov 01 '16 at 07:28
  • 1
    There is may (https://github.com/Xudong-Huang/may) which is a green thread implementation. – Terry Shi May 21 '21 at 21:34
  • @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 – Captain_Obvious Sep 22 '21 at 18:49
  • @Captain_Obvious 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;` – Venryx Jan 20 '22 at 05:36