Earlier quoted context omitted.
Those lose zero-overhead interop with C, which is a core constraint for Rust. Your guesses are incorrect.
> lose zero-overhead interop How many LOC is tokyo nowadays?
Tokyo is a city
Inside Rust's Async Transform
61–70 of 84 posts
Re: Inside Rust's Async Transform
#62[deleted]
Re: Inside Rust's Async Transform
#63I'll take fibers that yield automatically on blocking operations over async/await most days for most tasks. It's slightly less flexible, since you can only wait for one async action at a time per fiber; but a pleasure to use in comparison. But for that you need fibers built in. Go sort of does the same thing, but insists on running fibers in separate threads at its convenience; which means giving up the lovely simpli…
Have you given Erlang a look? What it calls processes sound like what you call fibers; although it does have quasi-premptive yielding as well as yielding when waiting for a message. Since Erlang is built on async message passing, you can easily send a request and block on the response, but you can also send multiple requests and process the responses as they arrive.
Re: Inside Rust's Async Transform
#64> Instead of thinking of a CPS-like transform where an async function is split into a series of continuations that are chained together via a Future::then method, Rust instead uses a generator/coroutine transform to turn the function into a state machine
State machines are also what Clojure(Script) core.async uses.
(Easy choice as there are no continuations available)
Re: Inside Rust's Async Transform
#65Re: Inside Rust's Async Transform
#66Re: Inside Rust's Async Transform
#67Bikeshedding: I think Solarized light/dark color themes have insufficient contrast ratios.
Re: Inside Rust's Async Transform
#68(shameless plug) The state machine approach is one I used in an old sweetjs library called cspjs[1] which implemented async tasks into JavaScript well before async/await. I still think there are some good ideas left there - especially async error handling and native "data flow variables".
Re: Inside Rust's Async Transform
#69Why this instead of "green threads"? Runtime overhead/footprint?
Re: Inside Rust's Async Transform
#70Why this instead of "green threads"? Runtime overhead/footprint?
Yep.