4 ms·

How does the async/await story in Rust compare with C#? In C# it feels 95% done and the remaining 5% can lead to some significant confusion.

bouke 5y ago
Can you expand on the 5%?
- rawling 5y ago
  ConfigureAwait, probably
- sershe 5y ago
  C# story is a classic example of well-implemented, but leaky abstraction. I would say 99% of the time it works fine and very intuitive. Then 1% of the time something utterly bizarre happens, I've definitely seen very un-intuitive examples when await is used with ContinueWith spawned in an unconventional manner, and the things get hopelessly muddled (you await task t in try-finally but finally only executes after some task that is not part of t completed is something I've seen iirc). I've also seen un-intuitive perf issues with await where replacing it with manual continuations sped things up a lot; again, I think it's very rare, but when it happens it happens. And yeah like the other comment mention, ConfigureAwait 0_o
GolDDranks 5y ago
It still feels like a prototype. There's still lack of integration with some major language features such as traits, and the standard library is missing all but the most rudimentary primitives; third party libraries help, but at the moment you are required to "takes sides" which async runtime library ecosystem you choose to use (for example, to spawn tasks), even though the thing you are doing doesn't require anything specific from that library. Finally, there are unsolved design problems about cancellation and destructors. And some murky behind-the-scenes stuff about the memory safety and soundness of self-referential types (which Futures often are). I think that at least the trait integration stuff is taking some steps forward these days, and hopefully the cancellation stuff too, which this blog post is indicative of.
- GolDDranks 5y ago
  To be sure, Rust is trying to solve very hard problems here, given to requirements: the async system is supposed to work in very high-performance situations, without allocators on embedded etc., while trying to keep the individual features that support the system relatively straightforward and orthogonal. It feels like there has been not much progress since the initial release of async in 2018, but it's a good thing that the designs are not rushed.
  - pas 5y ago
    Ergonomic async depends on a smarter type system (GAT), and a lot of progress has been made on that.
deleted 5y ago
[deleted]

bouke 5y ago

Can you expand on the 5%?

rawling 5y ago
ConfigureAwait, probably
sershe 5y ago
C# story is a classic example of well-implemented, but leaky abstraction. I would say 99% of the time it works fine and very intuitive. Then 1% of the time something utterly bizarre happens, I've definitely seen very un-intuitive examples when await is used with ContinueWith spawned in an unconventional manner, and the things get hopelessly muddled (you await task t in try-finally but finally only executes after some task that is not part of t completed is something I've seen iirc). I've also seen un-intuitive perf issues with await where replacing it with manual continuations sped things up a lot; again, I think it's very rare, but when it happens it happens. And yeah like the other comment mention, ConfigureAwait 0_o

GolDDranks 5y ago

It still feels like a prototype. There's still lack of integration with some major language features such as traits, and the standard library is missing all but the most rudimentary primitives; third party libraries help, but at the moment you are required to "takes sides" which async runtime library ecosystem you choose to use (for example, to spawn tasks), even though the thing you are doing doesn't require anything specific from that library. Finally, there are unsolved design problems about cancellation and destructors. And some murky behind-the-scenes stuff about the memory safety and soundness of self-referential types (which Futures often are). I think that at least the trait integration stuff is taking some steps forward these days, and hopefully the cancellation stuff too, which this blog post is indicative of.

GolDDranks 5y ago
To be sure, Rust is trying to solve very hard problems here, given to requirements: the async system is supposed to work in very high-performance situations, without allocators on embedded etc., while trying to keep the individual features that support the system relatively straightforward and orthogonal. It feels like there has been not much progress since the initial release of async in 2018, but it's a good thing that the designs are not rushed.
- pas 5y ago
  Ergonomic async depends on a smarter type system (GAT), and a lot of progress has been made on that.

deleted 5y ago

[deleted]