4 ms·

The answer to this question is quite involved. As you may already know, Rust at one time had a fiber model, but it was removed in favor of Futures. One big adv

The answer to this question is quite involved. As you may already know, Rust at one time had a fiber model, but it was removed in favor of Futures. 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.

cpuguy83 8y ago
In go toh can't control the polling mechanism if you are using the Builtin types. 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.
skyde 8y ago
I agree with you. I guess the best solution would be something in between “await” and goroutine. 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.
eptcyka 8y ago
> Rust at one time had a fiber model, but it was removed in favor of Futures. 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.

cpuguy83 8y ago

In go toh can't control the polling mechanism if you are using the Builtin types. 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.

skyde 8y ago

I agree with you. I guess the best solution would be something in between “await” and goroutine. 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.

eptcyka 8y ago

> Rust at one time had a fiber model, but it was removed in favor of Futures. 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.