[kazoomonger]

> But 10 years out it's not entirely implausible that if Rust had stuck with fibers that it may have driven the required OS improvements ...

Rust would've been a language nobody had heard of. It wouldn't have driven anyone to do anything because it wouldn't have had widespread adoption in the first place. As-is I'm using it in embedded programming and loving it. I certainly would never have picked Go for that.

I think you're not really understanding Rust's approach here. Green threads would be much too heavyweight to build into the language itself, and would mostly preclude it from being seriously used in interesting domains like embedded programming.

[kazoomonger]

Since I can't edit the above comment, one additional thought is that your criticism is valid for a language like Python, which has a much higher tolerance for abstractions such as green threads being built into the language itself. It would've been interesting if Python had gone with a solution other than async/await.

I'm also a little confused when you say "Rust started with green threading/fibers". I think the term "fiber" is overloaded here, but Rust did start with green threads (M:N preemptive multitasking). Rust now has support for cooperative multitasking via async/await. From what I can find of UCMG, it kind of misuses the term fiber. Looks like it's just green threads that the kernel is aware of?