3 ms·

I appreciate your perspective on this. I've been using the new Tasks from the Parallel Library and really enjoy them. But, once I started reading about the asyn

by vyrotek 15y ago

I appreciate your perspective on this. I've been using the new Tasks from the Parallel Library and really enjoy them. But, once I started reading about the async markup I was a little unsure as to what I gained from it since as you mentioned it's really just a new way to write the task. Personally, I haven't had the time to really sit down and play around with both to see how I feel about code legibility and maintainability between the two techniques. Are you aware of any extra functionality gained by marking methods async? It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.

masklinn 15y ago
> Are you aware of any extra functionality gained by marking methods async? As far as I know there isn't any, the gain is in code readability/simplicity from the POV of an imperative developer: async/await are hints which the compiler transforms into CPS by thunkifying code following an `await`. According to Eric Lippert's series on async/await[0], the compiler also performs complex code generation to try and make try/except blocks behave "sensibly" in this imperative-looking code. While necessary for the coding style, I still am not sure whether that's an advantage or a drawback of async/await. > It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods. Technically, from outside the method `async T foo()` is no different from `Task<T> foo()` I believe, it's only the internal detail which change (mostly composing async callees and returning the result of an async chain). On the other hand (again this is something drawn from Eric's post) alongside async/await the framework team will add new APIs the Tasks API set, one of them being "multiplexing" of tasks (waiting for all tasks of a set of tasks, or any task of the set, although I'm sure the community has already implemented that separately) [0] http://blogs.msdn.com/b/ericlippert/archive/tags/async/ http://blogs.msdn.com/b/ericlippert/archive/tags/async/

by vyrotek 15y ago

masklinn 15y ago

> Are you aware of any extra functionality gained by marking methods async? As far as I know there isn't any, the gain is in code readability/simplicity from the POV of an imperative developer: async/await are hints which the compiler transforms into CPS by thunkifying code following an `await`. According to Eric Lippert's series on async/await[0], the compiler also performs complex code generation to try and make try/except blocks behave "sensibly" in this imperative-looking code. While necessary for the coding style, I still am not sure whether that's an advantage or a drawback of async/await. > It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods. Technically, from outside the method `async T foo()` is no different from `Task<T> foo()` I believe, it's only the internal detail which change (mostly composing async callees and returning the result of an async chain). On the other hand (again this is something drawn from Eric's post) alongside async/await the framework team will add new APIs the Tasks API set, one of them being "multiplexing" of tasks (waiting for all tasks of a set of tasks, or any task of the set, although I'm sure the community has already implemented that separately) [0] http://blogs.msdn.com/b/ericlippert/archive/tags/async/ http://blogs.msdn.com/b/ericlippert/archive/tags/async/