5 ms·
I might be misunderstanding, but the third party libraries won’t be going anywhere, right? No one will be forced to use the runtime in std, if it’s added.
by mplanchard 7y ago
I might be misunderstanding, but the third party libraries won’t be going anywhere, right? No one will be forced to use the runtime in std, if it’s added.
- steveklabnik 7y agoThat is correct. It's not clear that we'll add one to libstd, but even if we do, it will have zero impact on folks using external runtimes. If we do add one to libstd, it will probably be a very simple one, mostly for convenience and prototyping, rather than something that tries to compete with the bigger runtimes.
- pjmlp 7y agoAnd what is the interoperability story across libraries that dependent on different runtimes?
- steveklabnik 7y agoIt depends. The major pain point right now is that there's no common API for spawning new tasks. Not every library does that though. It's still not clear what this has to do with being a "breaking change" though. Like, if I were to use the serde-json crate in my project, the fact that the json crate exists, but has a slightly different API, does not mean that somehow this is a "breaking change." Moving between two or three different libraries is not the same thing.
- pjmlp 7y agoWell it all depends on how interoperability will work across runtimes, otherwise you get silos depending on which runtime each library decides to use for their async/await code. Right now Rust is looking to have as many async/await variants as there are C++ string libraries, with the same amount of interoperability headaches.