My understanding is the main issue with “await” model is that you only abstract The Task model.
Running task don’t gave a real ID and stack like “Go” and “Erlang” you can list all running fiber how much memory and CPU they use ...
I believe you could write your own event loop easily in Go if they exposed the internal api used to pause and resume goroutine, you can already pause goroutine by having them wait on a mutex and resume them from your custom event loop by releasing that mutex.
You can drop to raw fd's and do whatever you like... of course this negates a lot of the niceties that go affords you.
No, fibers were removed with nothing to replace them. The futures as we know them today did not exist in the far, far past when fibers and the whole runtime thing got dropped.
One big advantage of Futures is they are decoupled from their execution environment.
For example, different types of executors can be used depending on the type of Future. For example, you may have an IOThreadPoolExecutor to handle accepting and responding to connections that should spend very little time blocking and a CPUThreadPoolExecutor for offloading heavy processing. In Go, you have no say in how goroutines are scheduled, you sacrifice control to reduce complexity.
Another big one in network programming is the polling mechanism. In Go, you have no control over your polling mechanism, whereas with a Future is decoupled from the event loop, and you can write your own event loop on any experimental kernel APIs you'd like.
Rust made the right move because in Rust, just as in C++, we want maximum control. Futures are more primitive, and it's possible to build coroutine models on top of them, but not vice versa.