4 ms·

The thing I like most about C# is the new 4.5 async method decorators CTP which are frankly async methods done right. For those not in the know, you just need

by boyter 15y ago

The thing I like most about C# is the new 4.5 async method decorators CTP which are frankly async methods done right. For those not in the know, you just need to add an async to the front of the method and then put in await on whatever operation is going to take a while. You can literally take synchronous network code modify a few methods and get 100x the throughput.

masklinn 15y ago
> You can literally take synchronous network code modify a few methods A few methods? Visible async taints, always (think haskell monads, because that's pretty much what it is), you have to convert the complete dynamic scope leading to those newly async method or it'll never work correctly. It's more than "a few methods" unless your system is absolutely trivial. So no, you literally can't do that, let alone literally. Not to mention, `async` marks the method as asynchronous, it does not make the method asynchronous: > put in await on whatever operation is going to take a while. That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. At the very least, this means wrapping "whatever operation" in a `TaskFactory.StartNew`. Not just adding an `await` to synchronous code. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.
- innes 15y ago
  That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation that is the hard bit. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. Everything is 'sugar over the assembly language API'.
- andersh 15y ago
  That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.
- 4deadaccounts 15y ago
  That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.
- 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/
topbanana 15y ago
Async/await is mostly a C#5 rather than .Net 4.5 thing. They could allow it to work against .Net 4 and even 3.5.
- jstclair 15y ago
  Not just could, but did: http://blogs.msdn.com/b/csharpfaq/archive/2012/04/26/async-targeting-pack-for-visual-studio-11-now-available-for-net-4-and-silverlight-5.aspx http://blogs.msdn.com/b/csharpfaq/archive/2012/04/26/async-t...
  - topbanana 15y ago
    That's just the CTP, it's not clear yet whether they will release that support.
apaprocki 15y ago
Async/await modeled after C# have been hacked into node.js as well: https://github.com/koush/node/wiki/%22async%22-support-in-node.js https://github.com/koush/node/wiki/%22async%22-support-in-no...
- untog 15y ago
  Interesting- it looks a lot like tame.js, but integrated into V8 itself. I wonder what the performance benefits are.

by boyter 15y ago

masklinn 15y ago

> You can literally take synchronous network code modify a few methods A few methods? Visible async taints, always (think haskell monads, because that's pretty much what it is), you have to convert the complete dynamic scope leading to those newly async method or it'll never work correctly. It's more than "a few methods" unless your system is absolutely trivial. So no, you literally can't do that, let alone literally. Not to mention, `async` marks the method as asynchronous, it does not make the method asynchronous: > put in await on whatever operation is going to take a while. That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. At the very least, this means wrapping "whatever operation" in a `TaskFactory.StartNew`. Not just adding an `await` to synchronous code. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.

innes 15y ago
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation that is the hard bit. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. Everything is 'sugar over the assembly language API'.
andersh 15y ago
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.
4deadaccounts 15y ago
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part. Ultimately, `async` and `await` still are nothing but sugar over the Tasks API. The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.
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/

topbanana 15y ago

Async/await is mostly a C#5 rather than .Net 4.5 thing. They could allow it to work against .Net 4 and even 3.5.

jstclair 15y ago
Not just could, but did: http://blogs.msdn.com/b/csharpfaq/archive/2012/04/26/async-targeting-pack-for-visual-studio-11-now-available-for-net-4-and-silverlight-5.aspx http://blogs.msdn.com/b/csharpfaq/archive/2012/04/26/async-t...
- topbanana 15y ago
  That's just the CTP, it's not clear yet whether they will release that support.

apaprocki 15y ago

Async/await modeled after C# have been hacked into node.js as well: https://github.com/koush/node/wiki/%22async%22-support-in-node.js https://github.com/koush/node/wiki/%22async%22-support-in-no...

untog 15y ago
Interesting- it looks a lot like tame.js, but integrated into V8 itself. I wonder what the performance benefits are.