>What I would give for a preemptive green-thread scheduler in Rust. They tried this in early versions of Rust and ended up removing it. Rust has lower-level c

>What I would give for a preemptive green-thread scheduler in Rust. They tried this in early versions of Rust and ended up removing it. Rust has lower-level constraints than Go that they didn't want to compromise on. E.g. performance constraints of FFI C-interopt with predictable fixed stack space. Those reasons mentioned in various subthreads: - https://lobste.rs/s/bfsxsl/ocaml_4_03_will_if_all_goes_well_support#c_whrcmk https://lobste.rs/s/bfsxsl/ocaml_4_03_will_if_all_goes_well_... - https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_await#c_wsg7e0 https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_aw... - https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_firmware#c_d0nzyb https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_fi... - https://news.ycombinator.com/item?id=21475154 https://news.ycombinator.com/item?id=21475154 As counterpoint, Rust's original designer, Graydon Hoare, prefers "green threads". In a recent blog post (2023-June), he mentioned that he understands why the Rust team got rid of it for performance reasons but he's not fully convinced of the ultimate tradeoff: -> Async/await. I wanted a standard green-thread runtime with growable stacks -- essentially just "coroutines that escape, when you need them too". Possibly with a somewhat-embeddable outer event loop / IO manager library, but that's always going to be a little tricky. Go started and stayed here, but they had to do a bunch of gory compromises to make the FFI work and it leaves a lot of performance on the table and torpedoes a bunch of embedding opportunities. Rust started here too, and it got rewritten a couple times and eventually thrown out because of a lot of reasons but none which completely obviated the need (as evidenced by the regrowth of Async/Await and Tokio). I've softened my position on this and have a grudging respect for where Rust wound up (especially in enabling heterogeneous selects, which I think puts it in a similar and enviable expressivity class as Concurrent ML). But if I'm being honest I never would have agreed to go in this direction "if I was BDFL" -- I never would have imagined it could even work -- and still don't know that I think the result quite pays for itself. -- from https://graydon2.dreamwidth.org/307291.html https://graydon2.dreamwidth.org/307291.html