3 ms·

for anyone interested in Rust's choice to not use the green thread model: https://www.reddit.com/r/rust/comments/7x0icm/regarding_green_threads/ https://www.re

for anyone interested in Rust's choice to not use the green thread model: https://www.reddit.com/r/rust/comments/7x0icm/regarding_green_threads/ https://www.reddit.com/r/rust/comments/7x0icm/regarding_gree... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... > Initially, Rust supported only the green threading model. Later, native threading was added and ultimately became the default.

nu11ptr 4y ago
I get why Rust opted for native threads vs. green threads as a default, esp. when they want to promote zero cost abstractions. What the above links don't cover, and what I'm interested in, is why async/await instead of M:N/green threads for the secondary "light weight" threading model. Was async/await easier to make "zero cost"? Or what was the reason?
- amaranth 4y ago
  In theory async/await can be compiled to something as efficient as if you wrote all the non-blocking logic by hand so yeah, it's a "zero cost" abstraction. For green threads the stdlib would have to be designed around them (again) or they'd feel like something bolted on the side with two sets of APIs for everything. This is also the case for async/await but that means green threads don't have an advantage there. If you have to worry about Task vs Thread, make sure you all the right APIs from each, figure out what to do for TLS in Tasks, etc then you may as well just use the one that is more efficient.