Item — HN Reader

Well, either the language will leave async runtimes in the domain of third-party libraries, which is the current approach. Or, the potential blessed one in std will be an alternative that you may or may not want to use in your code.

When I think of breaking changes, I think removing sun.misc.Unsafe. Which, yes yes, was never supposed to be used, but still was. Evolution of best practices and introduction of alternative implementations doesn't break anything.

1 comments

It does break, because those libraries need to interoperate and async/await doesn't work without linking to one of them.

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.

That 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.

And what is the interoperability story across libraries that dependent on different runtimes?

It 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.

Well 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.