2 ms·

I agree, there's questions that need to be answered, and I don't know that I even have answers to give to them. I will say, that its clear, to me and a good po

I agree, there's questions that need to be answered, and I don't know that I even have answers to give to them. I will say, that its clear, to me and a good portion of Rust users, that async in Rust needs DX improvements. Its one of the top features of the language that is used alot and people struggle with often[0] [0]: To be fair, async in any language trips up developers pretty often, though I think Rust can give someone a particularly bad time. Granted, I have not compared it to C / C++ as I don't do any development in either language currently

steveklabnik 3y ago
> I don't know that I even have answers to give to them. To be honest, this is why this discussion always gets frustrating: people demand change that is impossible, and then when pushed for how to accomplish the impossible, they throw up their hands. I do not think you or anyone else is doing it maliciously, but for some reason, on this specific topic, it happens endlessly.
- no_wizard 3y ago
  My best shot at this is something akin to a runtime built-in to the stdlib that can be opted out, similar to how you can build something with `no-std` so there is no reliance on `libstd`. Perhaps this is a great place where you drop into more "raw" async programming using the async / await primitives. You lose DX sugar but slim out the runtime for embedded work. Ideally, the runtime could handle anything written using lower level primitives as to not completely kneecap libraries that need to work with `no-async-runtime` (or whatever you want to call it). This would at least alleviate a common concern I hear around this, which is runtime bloat. That seems like a step in the right direction to integrate a unified async runtime with an alternative / better syntax[0] [0]: I want to note, that C# is the only language I ever worked in that supported async in two constructs. There is the traditional async / await, which is by far the most common. Before that though, there was event driven async programming (with support for background workers and other async features) and that is also still supported, and they can interop with each other (with some caveats)
  - steveklabnik 3y ago
    The only thing this would change is not needing to "cargo add smol" which already exists as a smaller runtime if you need it. That wouldn't solve the fact that a large part of the ecosystem would still need the features of Tokio, and would still use them. So you still have interoperability problems, until figuring out how to make runtimes swappable, and that is open-ended work. (and also assumes that smol's particular choices are correct for this, and that everyone maintaining the stdlib agrees that they are, and that the folks on the libs team are willing to step up and start maintaining an entire async runtime, etc etc etc)

steveklabnik 3y ago

> I don't know that I even have answers to give to them. To be honest, this is why this discussion always gets frustrating: people demand change that is impossible, and then when pushed for how to accomplish the impossible, they throw up their hands. I do not think you or anyone else is doing it maliciously, but for some reason, on this specific topic, it happens endlessly.

no_wizard 3y ago
My best shot at this is something akin to a runtime built-in to the stdlib that can be opted out, similar to how you can build something with `no-std` so there is no reliance on `libstd`. Perhaps this is a great place where you drop into more "raw" async programming using the async / await primitives. You lose DX sugar but slim out the runtime for embedded work. Ideally, the runtime could handle anything written using lower level primitives as to not completely kneecap libraries that need to work with `no-async-runtime` (or whatever you want to call it). This would at least alleviate a common concern I hear around this, which is runtime bloat. That seems like a step in the right direction to integrate a unified async runtime with an alternative / better syntax[0] [0]: I want to note, that C# is the only language I ever worked in that supported async in two constructs. There is the traditional async / await, which is by far the most common. Before that though, there was event driven async programming (with support for background workers and other async features) and that is also still supported, and they can interop with each other (with some caveats)
- steveklabnik 3y ago
  The only thing this would change is not needing to "cargo add smol" which already exists as a smaller runtime if you need it. That wouldn't solve the fact that a large part of the ecosystem would still need the features of Tokio, and would still use them. So you still have interoperability problems, until figuring out how to make runtimes swappable, and that is open-ended work. (and also assumes that smol's particular choices are correct for this, and that everyone maintaining the stdlib agrees that they are, and that the folks on the libs team are willing to step up and start maintaining an entire async runtime, etc etc etc)