5 ms·
From a rustacean perspective I'm wondering why they aren't copying Rust's Send/Sync traits. They work so well: they're purely a type-system thing, without being
by pornel 6y ago
From a rustacean perspective I'm wondering why they aren't copying Rust's Send/Sync traits. They work so well: they're purely a type-system thing, without being tied to any coroutine runtime. And they allow creation of multi-threaded primitives, like actors, queues, locks, async, etc. in libraries without baking them into the language.
- pjmlp 6y agoYeah, which then ends up in incompatible runtimes, no thanks.
- son_ngu 6y agoWhat do you mean by incompatible runtimes, can you give an example?
- pjmlp 6y agoYes, https://blog.logrocket.com/a-practical-guide-to-async-in-rust/ https://blog.logrocket.com/a-practical-guide-to-async-in-rus... > Some libraries require you to use a specific runtime because they rely on runtime internals to provide a solid API for you to use or wrap their own API around an existing runtime. One example is the actix_web web framework, which wraps its own API around tokio. So if you want to use two libraries that follow this approach, now you have faced with the hurdle to combine two async/await runtimes into the application. Even C++ knows better in this regard.
- Matthias247 6y agoWe had this discussion before. Please don't repeat wrong statements over and over. C++ is in no ways different from Rust in this regard - they all just provide a coroutine transformation and future type, but not a builtin executor. And there is nothing more interoperable about C++ solution than about Rusts. Actually Rust ones might even be better, since there is at least a well-defined interface that executors should follow (through the `Waker` type). The C++ executor interface discussion is probably older than the coroutines proposal, but afaik there still hasn't happened any standardization.
- pornel 6y agoYou're confusing it with runtimes for Futures executors. Separating runtimes from the basic concept of thread-safety is the whole point. Everything around Send/Sync is perfectly interoperable, because it's a rule for static analysis, not a runtime.
- chrislattner 6y agoI agree for part of it at least, see this writeup which is directly related to Send: https://docs.google.com/document/d/1OMHZKWq2dego5mXQtWt1fm-yMca2qeOdCl8YlBG1uwg/edit https://docs.google.com/document/d/1OMHZKWq2dego5mXQtWt1fm-y...