3 ms·

I still remember first hearing about Rust and how it was using Green Threads, then out of the blue a year later passes or months, and I'm reading that it doesn'

I still remember first hearing about Rust and how it was using Green Threads, then out of the blue a year later passes or months, and I'm reading that it doesn't do any of that anymore, it's basically C++ on steroids mixed with functional programming. I never did look up why they gave up on Green threads and other things, I wonder if they faced similar challenges?

wyager 2y ago
Rust has settled into an excellent design niche where the language does not provide any features that require a language runtime. Rust's async/await is a purely compile-time feature, with no runtime support required. This is extremely powerful because it means you can do things like easily run async code on embedded devices with no OS. To run async code in rust, you bring your own executor. The most popular one is tokio (for desktop OSs), but you also have stuff like pollster (for running async code as blocking code) and embassy or RTIC (for embedded).
- jtrueb 2y ago
  Agreed, as much as there are complaints about usability of async in Rust, many alternatives proposed would fail in resource constrained systems. Green threading would be impossible or very limiting on embedded, where each stack eats away at something like 1-2% of memory and allocation is likely impossible or prohibitively expensive. I do note that some of the futures are starting to take up a couple KiB of RAM and ROM.
- eknkc 2y ago
  I might be completely wrong as I only played with rust but the current method seems to couple any async libraries you’d like to write to the executor. Which feels wrong imo. Would it be feasible to provide async io (file, network) code in std and let the executors execute? Or even some std traits that abstract the filesystem, network etc so that the executors can bring their own implementations but at least library code could only depend on std?
  - wyager 2y ago
    Correct, libraries do have to either pick a specific async IO library or use a trait for async IO. I have seen some of the latter in embedded-land, although I'm not sure if it's used in desktop async rust as well. The rust compiler currently discourages async traits with a warning, which seems wrong to me, but we use them extensively in embedded anyway.
    - anonymoushn 2y ago
      The feature is less than 1 year old, so a lot of the ecosystem couldn't use the feature because of being written before the feature existed. It does seem silly to have a warning today.
- anonymoushn 2y ago
  This is a fine approach but it's trivial to ship green threads with no runtime support as well. Various libraries implementing the feature exist for C or Zig etc.
  - kbolino 2y ago
    If you can accept cooperative scheduling that runs tasks only on a single core, then yes, lightweight solutions exist. This is more like "event-driven coroutines" than "green threads" though. If you want "full" green threads with preemptive scheduling and parallel execution across multiple cores, then an active runtime is needed.
dboreham 2y ago
User level (aka green) threading is difficult. Very few implementations work (Erlang, Golang, <any others>+) and it takes a great deal of time and effort to get to that "fully working" state. +Perhaps the new Java fiber stuff works but I don't have enough data to be sure yet.
Ygg2 2y ago
There were plans for green threads, however, green threads were abandoned due to runtime costs around like 6 years ago? https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... EDIT: 10 years ago.
- steveklabnik 2y ago
  It’s coming up on ten years. Time flies.
  - Ygg2 2y ago
    I thought it was 2018, it was 2014 instead.
- anonymoushn 2y ago
  "green threads" as discussed in TFA don't require a runtime. The relevant issues are maybe https://github.com/rust-lang/rust/issues/33368 https://github.com/rust-lang/rust/issues/33368 and https://internals.rust-lang.org/t/what-is-the-current-safety-story-for-library-based-stackful-coroutines/14863/16 https://internals.rust-lang.org/t/what-is-the-current-safety...
steveklabnik 2y ago
https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... Note this was in 2014, before Rust 1.0.
- hyutmyjahsd 2y ago
  I miss peak rust.
- giancarlostoro 2y ago
  Yes it was a while back, wow 10 years.
jasode 2y ago
>I still remember first hearing about Rust and how it was using Green Threads, [...] I never did look up why they gave up on Green threads It's because green threads have unavoidable performance costs. I collected various threads that has Rust contributors explaining the costs they didn't want to pay: https://news.ycombinator.com/item?id=39062953 https://news.ycombinator.com/item?id=39062953 A language like Go is willing to pay those performance costs because they deliberately sit at a higher level of abstraction than lower-level Rust. Each chose different tradeoffs for different goals: - Golang : green threads worth the perf cost to gain higher productivity (goroutines, channels, etc) for the type of programs that Go programmers like to write - Rust : green threads are not worth the perf cost so as to not sacrifice the best possible performance for the type of programs Rust programmers like to write You can't have a language+runtime that satisfies both camps 100% perfectly. The language designer must choose the tradeoff. But because this tradeoff decision is not blatantly well-known and disseminated ... it also perpetually confuses Language X proponents on why Language Y didn't do the same thing as Language X.
- 01HNNWZ0MV43FF 2y ago
  What do Go channels do that takes advantage of their green threads?
- giancarlostoro 2y ago
  Thank you for this! This is exactly why I posted my comment, I was hoping someone would share some insight about Rust.
zamalek 2y ago
Rust can have green threads. It depends on the reactor. The abstraction sits one level lower than nearly everything else out there.

wyager 2y ago

Rust has settled into an excellent design niche where the language does not provide any features that require a language runtime. Rust's async/await is a purely compile-time feature, with no runtime support required. This is extremely powerful because it means you can do things like easily run async code on embedded devices with no OS. To run async code in rust, you bring your own executor. The most popular one is tokio (for desktop OSs), but you also have stuff like pollster (for running async code as blocking code) and embassy or RTIC (for embedded).

jtrueb 2y ago
Agreed, as much as there are complaints about usability of async in Rust, many alternatives proposed would fail in resource constrained systems. Green threading would be impossible or very limiting on embedded, where each stack eats away at something like 1-2% of memory and allocation is likely impossible or prohibitively expensive. I do note that some of the futures are starting to take up a couple KiB of RAM and ROM.
eknkc 2y ago
I might be completely wrong as I only played with rust but the current method seems to couple any async libraries you’d like to write to the executor. Which feels wrong imo. Would it be feasible to provide async io (file, network) code in std and let the executors execute? Or even some std traits that abstract the filesystem, network etc so that the executors can bring their own implementations but at least library code could only depend on std?
- wyager 2y ago
  Correct, libraries do have to either pick a specific async IO library or use a trait for async IO. I have seen some of the latter in embedded-land, although I'm not sure if it's used in desktop async rust as well. The rust compiler currently discourages async traits with a warning, which seems wrong to me, but we use them extensively in embedded anyway.
  - anonymoushn 2y ago
    The feature is less than 1 year old, so a lot of the ecosystem couldn't use the feature because of being written before the feature existed. It does seem silly to have a warning today.
anonymoushn 2y ago
This is a fine approach but it's trivial to ship green threads with no runtime support as well. Various libraries implementing the feature exist for C or Zig etc.
- kbolino 2y ago
  If you can accept cooperative scheduling that runs tasks only on a single core, then yes, lightweight solutions exist. This is more like "event-driven coroutines" than "green threads" though. If you want "full" green threads with preemptive scheduling and parallel execution across multiple cores, then an active runtime is needed.

dboreham 2y ago

User level (aka green) threading is difficult. Very few implementations work (Erlang, Golang, <any others>+) and it takes a great deal of time and effort to get to that "fully working" state. +Perhaps the new Java fiber stuff works but I don't have enough data to be sure yet.

Ygg2 2y ago

There were plans for green threads, however, green threads were abandoned due to runtime costs around like 6 years ago? https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... EDIT: 10 years ago.

steveklabnik 2y ago
It’s coming up on ten years. Time flies.
- Ygg2 2y ago
  I thought it was 2018, it was 2014 instead.
anonymoushn 2y ago
"green threads" as discussed in TFA don't require a runtime. The relevant issues are maybe https://github.com/rust-lang/rust/issues/33368 https://github.com/rust-lang/rust/issues/33368 and https://internals.rust-lang.org/t/what-is-the-current-safety-story-for-library-based-stackful-coroutines/14863/16 https://internals.rust-lang.org/t/what-is-the-current-safety...

steveklabnik 2y ago

https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... Note this was in 2014, before Rust 1.0.

hyutmyjahsd 2y ago
I miss peak rust.
giancarlostoro 2y ago
Yes it was a while back, wow 10 years.

jasode 2y ago

>I still remember first hearing about Rust and how it was using Green Threads, [...] I never did look up why they gave up on Green threads It's because green threads have unavoidable performance costs. I collected various threads that has Rust contributors explaining the costs they didn't want to pay: https://news.ycombinator.com/item?id=39062953 https://news.ycombinator.com/item?id=39062953 A language like Go is willing to pay those performance costs because they deliberately sit at a higher level of abstraction than lower-level Rust. Each chose different tradeoffs for different goals: - Golang : green threads worth the perf cost to gain higher productivity (goroutines, channels, etc) for the type of programs that Go programmers like to write - Rust : green threads are not worth the perf cost so as to not sacrifice the best possible performance for the type of programs Rust programmers like to write You can't have a language+runtime that satisfies both camps 100% perfectly. The language designer must choose the tradeoff. But because this tradeoff decision is not blatantly well-known and disseminated ... it also perpetually confuses Language X proponents on why Language Y didn't do the same thing as Language X.

01HNNWZ0MV43FF 2y ago
What do Go channels do that takes advantage of their green threads?
giancarlostoro 2y ago
Thank you for this! This is exactly why I posted my comment, I was hoping someone would share some insight about Rust.

zamalek 2y ago

Rust can have green threads. It depends on the reactor. The abstraction sits one level lower than nearly everything else out there.