4 ms·
It feels like you're complaining about things in the Rust language without taking the time to understand how the language idioms work. RTFM. Additionally, you'
by hguant 7y ago
It feels like you're complaining about things in the Rust language without taking the time to understand how the language idioms work. RTFM.
Additionally, you're making snarky comments about how you don't like how the base language doesn't handle something like JS...then reference a third party JS library. Base JS doesn't solve your 'problem' either.
To answer your question, async/await provides hooks for an executor (tokio being the most common) to run your code. You things like that in the executor.
https://docs.rs/tokio/0.2.0-alpha.6/tokio/executor/index.html https://docs.rs/tokio/0.2.0-alpha.6/tokio/executor/index.htm...
- ralusek 7y agoI reference a third-party library to show that you have full control of this stuff in user-space. Implementing Promise.all or Promise.map in userspace is trivial. I'm not complaining about things without taking the time to understand how the language works, I'm giving examples of things that don't seem possible based off of my understanding of how the language works...in hopes that someone will either clarify or accept that this is a shortcoming.
- roblabla 7y agoRust and JS have very very different execution models. You can absolutely control how many futures are allowed to make progress at the same time fully in userspace. If you're joining N futures, and want to only allow M futures to make progress at a time, make an adapter that only calls the poll function of M futures at a time, until those futures call ready. Rust gives you all the flexibility you need here. It might not be trivial yet because all the adapters might not be written yet, but that's purely a maturity problem. The `join` macro does nothing magical. Go check out its implementation, and it will make it obvious how to implement a concurrency argument.
- deleted 7y ago[deleted]