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_...
- https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_aw...
- https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_fi...
- 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.