Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.
.NET is used by millions of developers. Strong and scalable foundations matter, and performance is an explicit goal with asp.net being one of the fastest web frameworks. Async is a core part of this.
There's very little - if any - overhead that you need to worry about with async code from the language to Visual Studio.
it actually uses more resources. async has a cost, but it is really low.
Threads have their own resource cost.
Exactly. So when you await it, that thread that would have but blocked waiting for the I/O instead can be used to service other requests until the I/O has finished.
Concurrency is not parallelism [1].
Both solve the same problem with the same technique (under the hood it is all the same). One language had the benefit of late birth (go), the other suffers with its friends through a library/language migration (C#, C++, Java, JavaScript, Python, ...). async/await is effectively the modernization of structural programming to benefit from modern concurrency.
While async/await is nowhere structurally as capable/composable as for instance Haskell's do notation, it's still more composable than a lot of alternatives and a lot of manual thread management techniques.
The biggest thing though is that these concerns are orthogonal. You can have green threads backing an async/await monad (with some caveats), but you can't as easily swap in anything that follows monad rules into code written specifically just for green threads. (Python makes you explicitly define your threading model before using async/await; the others provide methods to configure it.)
Which is to say "late birth" isn't really a consideration in async/await, it's as much a consideration of flexibility/composition of abstractions. JS, for example, needed that flexibility/composition in the wild west of multiple disparate Promise implementations early on, and may need it again if/when Browsers ever decide to support proper multi-threading whether it is green threads or something else. In such a future you should still be able to compose existing async/await code without modifying it, even as you take advantage of newer threading options.
I'm a huge fan of Go, but pretending the two systems are equivalent either is either disingenuous or belies misunderstanding.
Some articles:
https://docs.microsoft.com/en-us/archive/blogs/vancem/diagno...
https://github.com/Microsoft/vs-threading/blob/master/doc/th...
Synchronous code locks you into the model of handling one request per thread.
Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.
Whats a way to get the utility of normal debugging while using async?
Using a good IDE (Rider or Visual Studio), debugging async/await code works as expected.
Are you doing interop or calling unmanaged code?
https://www.ageofascent.com/2018/01/26/stack-trace-for-excep...