| > Not only is it [linearly written code with async/await] easier to read (as the chaining example was), but now the error handling behavior is the exact same as regular synchronous JavaScript code. Then why not write code synchronously in the first place? I understand that async/await looks attractive in languages with an event loop model, such as Javascript, or with expensive threads, such as C#. I see two main justifications for async/await in these languages:
1. Linear code.
2. More performant code. It's easier to follow a linear flow of code than it is to follow entangled callbacks and state machines. Async/await is also sometimes perceived to help with performance. This is an observation that is typically made in languages with few, heavy threads, such as C#. As async/await code "doesn't block", expensive thread resources are mostly free to execute concurrent async/await code. It seems to me that async/await provides very little apart from making code flow over callbacks look like regular, synchronous, structured, procedural code. It introduces new concepts: Now there are two types of function calls: vanilla "blocking" function calls and the new async function calls. The difference is that one "blocks" or "takes a long time" whereas the other does not. Some APIs are only available in one flavor. How do I adapt between the two conventions in code that is required to deal with both API types? C# and the .NET framework mostly choose to completely double API surface - for example you now have a System.IO.Stream with both vanilla and async/await Read()/Write() etc. methods. You can only hope that they're implemented in a consistent fashion. (they're not) Given all these conceptual and practical disadvantages I don't understand how async/await becomes such a praised thing. I'm in favor of coroutines/green threads/goroutines (depending on whether you learned programming in the 1970ies, 1990ies or 2010ies ;)) with a scheduler that multiplexes I/O to the appropriate OS concepts for concurrency. With this approach you get the benefits of structured, procedural programming without the mental and practical disadvantages of async/await. |