Every time I see another poll about the @rustlang async/await syntax, I feel like it's missing the option "I just want async/await to be stable and will defer to the Rust Core team's best judgment about the syntax"
-
-
I don’t see how that necessarily follows, but I’ll believe you
-
It’s mostly all about malloc perf. Async/await avoids allocations (alliteration!) BTW, the syscall cost of spawning a thread on Linux is a lot less than the cost of allocating the stack.
- 13 more replies
New conversation -
-
-
Honestly, I'd be happy with threads and type safe queues (eg. like python's Queue). Performance is more your gig than mine, but as a programmer I can say that these are a total disaster: - async/await - Promises - Events
-
There’s a lot to be said for a “ThreadPoolExecutor” driven by an I/O reactor (see also: Disruptor) but that model best suits apps with a single/few core behaviors and not a complex set of interacting asynchronous behaviors
- 1 more reply
New conversation -
-
-
We have a coroutine library, BTW: mioco. It isn’t used much because it isn’t much faster than threads and adds a lot of complexity to FFI interop. Most people want either “easy and pretty fast” (threads) or “as fast as possible” (futures with async/await sugar).
-
Rust noob here. Can I get a TLDR on coroutines or threads vs futures? (I already understand the difference between coroutines and threads)
- 1 more reply
New conversation -
-
-
Ok, this plagued me all night... how do you do async/await without allocating more stacks?
-
Can’t give you a super in depth answer right now, but async/await compiles to a generator, and you give that generator one, single, exactly sized stack.
- 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.