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"
-
-
This Tweet is unavailable.
-
I don’t have up-to-date numbers but I know it was a pretty big difference on really high C10K-style workloads. Alex, Carl, etc. probably can cite you some benchmarks.
- 11 more replies
-
-
-
Put another way, basically in the Rust community "requires malloc" is synonymous with "DOA" unless the use of malloc is a temporary hack that people plan to eventually remove. Also legacy; async/await has a clear migration path from futures which is what people currently use.
-
None of this played any role whatsoever in the decision to move forward with futures and async/await. This is offensive and denigrating speculation
- 10 more replies
New conversation -
-
-
Sure, but the cost is amortized over the life of the thread? If you’re spawning a thread to do 1 thing only, rather than burning down a queue of tasks, sure
-
You’re right of course for long-lived threads. What people use async/await for is C10K (10,000 simultaneous short-lived threads). Then the stacks start to hurt, even if you cache them.
End of conversation
New conversation -
-
-
One thing I'd love to see come out of this: embedded projects adopting async/await. I think it would be very cool if in something like cortex-m-rtfm tasks could "await" on messages from other tasks, interrupts, or on the timer queue: https://crates.io/crates/cortex-m-rtfm …
- End of conversation
New conversation -
-
-
Core only, no allocations required, though that means a fixed number of tasks and maximum task size, etc
End of conversation
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.
