Implicit async/await

[BEagle1984]

I wonder why it has been decided to introduce the async/await keywords to implement the state machine. They pollute all our code and make it hard to mix async and sync code. Many times you end up duplicating code in the libraries, to provide both a sync and an async version of every API.

Why can't the runtime just figure out when there's some I/O going on and implicitly implement the state machine?

What's the advantage of explicitly deciding when and how to implement or use an async API? Also, why wouldn't you want to use the async way?
If it is to allow for optimizations (avoiding the state machine's overhead), couldn't that be solved via an annotation like [PleaseNoAsyncFromHereOn] to be placed on the few methods where it makes sense?

I'm probably missing a lot of background so I'm looking forward to informative replies.

[HaloFour]

The C# team wanted there to be a very clear delineation for asynchronous boundaries, both because of the overhead of the state machine and because you are likely to switch between threads which can have a direct impact on how your code behaves. Anything thread-affine, like thread locals, locking, etc., effectively break in these cases, and without compiler support and understanding it would be very easy to write code that relies on these features that will not work correctly at runtime.

If you want a different perspective on how async can be implemented in a language you can check out OpenJDK Loom, which aims to bring user-mode threads to the Java language. It does sound enticing but there are a lot of caveats with this design. It makes the giant assumption that the runtime has enough control over the ways to perform blocking I/O that can be rewritten to support parking the user-mode thread, and the list of cases that aren't supported is a lot longer than you might think. For example, synchronized (the Java version of lock) "pins" the carrier thread and prevents the runtime from parking the user-mode thread resulting in blocking. Any native calls on the stack do the same. Many I/O operations simply can't be made user-thread-compatible, and which ones can differ by platform and OS support. It makes the solution pretty brittle, and if you're familiar with async projects it doesn't take a lot of accidental blocking to bring the entire system down.

In the C# world, which has a much wider and diverse ecosystem and encourages the mixing of native code, I think something like user-mode threading would be untenable. Something like async/await provides an intentional seam and API with a predictable contract that doesn't require those runtime assumptions.

[BEagle1984]

Thank you @HaloFour. This question was exactly triggered by Loom and I was exactly wondering why we couldn't have something that looks so cool on paper. 😎
I see it's way more complex than it sounds. I'm very curious to see how far will they be able to bring it. In the meanwhile we will keep duplicating I guess. 🤣

[virzak]

The duplication part can be resolved using https://github.com/zompinc/sync-method-generator