3 ms·
It's a common problem with many languages - I've experienced it recently myself with Rust's futures. It requires you to be explicit about spawning tasks since t
by akiselev 6y ago
It's a common problem with many languages - I've experienced it recently myself with Rust's futures. It requires you to be explicit about spawning tasks since that requires a heap allocation and it took me a while to figure out that I had to explicitly include an async runtime (of which there are several) and start up the async tasks myself.
That said, I agree with the GP. I immediately saw that it was going to execute sequentially and thought nothing of it. Most of the time I use async/await not for concurrency but for syntax sugar and to get proper exceptions from promise based APIs instead of the GOTO FAIL control flow breaking nonsense that is catch().
- steveklabnik 6y agoIt doesn't inherently require a heap allocation, but the common, non-embedded use case does.
- akiselev 6y agoYeah I was glossing over the specifics for this context. The way futures/generators are implemented as syntax sugar over a closure/state machine that can live on the stack is one of my favorite features of Rust, but i.e. an executor that uses a smallvec task queue is a bit esoteric for a discussion that started around Javascript.