3 ms·

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

by dmit 6y ago

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.

pjmlp 6y ago
It does break, because those libraries need to interoperate and async/await doesn't work without linking to one of them.
- mplanchard 6y 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 6y ago
    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.
    - pjmlp 6y ago
      And what is the interoperability story across libraries that dependent on different runtimes?
      - steveklabnik 6y ago
        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.
  - pjmlp 6y ago
    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.

by dmit 6y ago

pjmlp 6y ago

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

mplanchard 6y 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 6y ago
  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.
  - pjmlp 6y ago
    And what is the interoperability story across libraries that dependent on different runtimes?
    - steveklabnik 6y ago
      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.
- pjmlp 6y ago
  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.