3 ms·

Asynchronous Programming with Async and Await (C# and Visual Basic)

67 points by fosk 15y ago

varunsrin 15y ago
Been using this in a new Win8 app I'm working on - I have to say, the await keyword and the Task<T> object make the code much cleaner
- nathanwdavis 15y ago
  From what I've heard, you can't use Task<T> for WinRT components that expose async methods. Instead you have to use IAsyncOperation as the return type. This limitation seems kind of annoying IMHO. Reference: Miguel de Icaza's blog post http://tirania.org/blog/archive/2011/Sep-15.html http://tirania.org/blog/archive/2011/Sep-15.html
  - kenjackson 15y ago
    Only if you're doing C++. If you're in C#/VB, you still use Task. http://msdn.microsoft.com/en-us/library/windows/apps/hh464924(v=VS.85).aspx#asynchronous_patterns_in__with_c_ http://msdn.microsoft.com/en-us/library/windows/apps/hh46492... I think that's because the TPL doesn't exist for C++.
  - varunsrin 15y ago
    So after toying with it for a couple of hours, here's what I've seen: I think if the method is named 'Async' (such as GetReplyAsync() *) , you can call it asynchronously with the new await in C#, and using Task<T> as the return type. Only methods that are lableled async implement the new 'await'. Some of the old .NET methods had 2 API's - synchronous & asyncrhonous. Some of the synchronous implementations, as pointed out in your link, have been deprecated. A few of the async methods I have seen (which do not have Async in the title), only accept the old IAsync/callback and do not work with await. Presumably, they do not implement the new C#5 style of async yet. Hopefully, they will at some point, because I'm a big fan of how clean & readable async C# can be now. Again I haven't explored C#5.0 thoroughly, these are just my first impressions.
kogir 15y ago
This is what sparked my interest in F# originally, and I love it. For the first time ever I'm willing to write async code regularly in C#. I can't wait for something like this to make its way to python (for twisted) or JavaScript (for node).
- RexM 15y ago
  It looks like this functionality has been ported to node, have a look: https://github.com/koush/node/wiki/%22async%22-support-in-node.js https://github.com/koush/node/wiki/%22async%22-support-in-no...
- bitsai 15y ago
  See this comment from MostAwesomeDude in a different thread: http://news.ycombinator.com/item?id=3051142 http://news.ycombinator.com/item?id=3051142 Perhaps it would be interesting to see how it was done in Twisted: http://http://twistedmatrix.com/documents/current/api/twisted.internet.defer.html#inlineCallbacks http://http://twistedmatrix.com/documents/current/api/twiste... We'd like to think that the C# guys were looking our way when they came up with async/await, but there's no proof. :3
- sah 15y ago
  I'm one of the authors of a Python framework called monocle for doing async programming in this style. It works with twisted and tornado. http://github.com/saucelabs/monocle http://github.com/saucelabs/monocle
Jacob4u2 15y ago
Why in the world would someone include the words Visual Basic in the title of a submission to Hacker News? And how in the world does that article get to the front page?
- jigs_up 15y ago
  VB.net isn't terrible. It enabled me to transfer all of my programming knowledge from VB6 into the .NET world, then move on to C# and ultimately other languages. Thank god for VB.net as far as I'm concerned.
  - nathanwdavis 15y ago
    Agreed, I can't dis it because it's what introduced me to OOP. That said, I'm glad I haven't had to do any VB for 8 years now. There are a host of other languages (Javascript, Ruby, C#, Erlang, Coffeescript, even C++) I prefer to program with.
- gokhan 15y ago
  Why c# is OK but VB is not? They both have the same feature set with different syntax. VB, as the language, is more powerful at the moment than Java, for example. Got genetics, lambda, linq for years and now async/await. Java OK, VB not? Come on :)
  - nathanwdavis 15y ago
    Genetics, cool!! Accounting for genetic drift must be a bitch though.
    - gokhan 15y ago
      Yep, generics, my bad.
  - Jacob4u2 15y ago
    Even though I started this whole religious war thread, I don't really want to continue with it (but I'm too proud to delete my comment). Here is my rebuttal in a nutshell; VB is not succinct and therefore not a powerful language[1]. [1] http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html
yread 15y ago
> In C#, the modifier can be applied to a method, a lambda expression, or an anonymous method. In all other contexts, the term is interpreted as an identifier. Wow so you can have your cake and eat it! await is an accepted "keyword" but it's not actually a keyword as far as parser is concerned. Cool! I wish other compilers were this conscious of backwards compatibility.
- lmkg 15y ago
  C# has been pretty scrupulous about using contextual keywords instead of reserved keywords when they add new language features. That's why, e.g., they went with "yield return foo" instead of the more traditional "yield foo." They also let you define "var," which normally denotes type inference, as a normal type, and "var" will refer to the defined type in contexts where it is accessible.

67 points by fosk 15y ago

Been using this in a new Win8 app I'm working on - I have to say, the await keyword and the Task<T> object make the code much cleaner

nathanwdavis 15y ago
From what I've heard, you can't use Task<T> for WinRT components that expose async methods. Instead you have to use IAsyncOperation as the return type. This limitation seems kind of annoying IMHO. Reference: Miguel de Icaza's blog post http://tirania.org/blog/archive/2011/Sep-15.html http://tirania.org/blog/archive/2011/Sep-15.html
- kenjackson 15y ago
  Only if you're doing C++. If you're in C#/VB, you still use Task. http://msdn.microsoft.com/en-us/library/windows/apps/hh464924(v=VS.85).aspx#asynchronous_patterns_in__with_c_ http://msdn.microsoft.com/en-us/library/windows/apps/hh46492... I think that's because the TPL doesn't exist for C++.
- varunsrin 15y ago
  So after toying with it for a couple of hours, here's what I've seen: I think if the method is named 'Async' (such as GetReplyAsync() *) , you can call it asynchronously with the new await in C#, and using Task<T> as the return type. Only methods that are lableled async implement the new 'await'. Some of the old .NET methods had 2 API's - synchronous & asyncrhonous. Some of the synchronous implementations, as pointed out in your link, have been deprecated. A few of the async methods I have seen (which do not have Async in the title), only accept the old IAsync/callback and do not work with await. Presumably, they do not implement the new C#5 style of async yet. Hopefully, they will at some point, because I'm a big fan of how clean & readable async C# can be now. Again I haven't explored C#5.0 thoroughly, these are just my first impressions.

kogir 15y ago

This is what sparked my interest in F# originally, and I love it. For the first time ever I'm willing to write async code regularly in C#. I can't wait for something like this to make its way to python (for twisted) or JavaScript (for node).

RexM 15y ago
It looks like this functionality has been ported to node, have a look: https://github.com/koush/node/wiki/%22async%22-support-in-node.js https://github.com/koush/node/wiki/%22async%22-support-in-no...
bitsai 15y ago
See this comment from MostAwesomeDude in a different thread: http://news.ycombinator.com/item?id=3051142 http://news.ycombinator.com/item?id=3051142 Perhaps it would be interesting to see how it was done in Twisted: http://http://twistedmatrix.com/documents/current/api/twisted.internet.defer.html#inlineCallbacks http://http://twistedmatrix.com/documents/current/api/twiste... We'd like to think that the C# guys were looking our way when they came up with async/await, but there's no proof. :3
sah 15y ago
I'm one of the authors of a Python framework called monocle for doing async programming in this style. It works with twisted and tornado. http://github.com/saucelabs/monocle http://github.com/saucelabs/monocle

Jacob4u2 15y ago

Why in the world would someone include the words Visual Basic in the title of a submission to Hacker News? And how in the world does that article get to the front page?

jigs_up 15y ago
VB.net isn't terrible. It enabled me to transfer all of my programming knowledge from VB6 into the .NET world, then move on to C# and ultimately other languages. Thank god for VB.net as far as I'm concerned.
- nathanwdavis 15y ago
  Agreed, I can't dis it because it's what introduced me to OOP. That said, I'm glad I haven't had to do any VB for 8 years now. There are a host of other languages (Javascript, Ruby, C#, Erlang, Coffeescript, even C++) I prefer to program with.
gokhan 15y ago
Why c# is OK but VB is not? They both have the same feature set with different syntax. VB, as the language, is more powerful at the moment than Java, for example. Got genetics, lambda, linq for years and now async/await. Java OK, VB not? Come on :)
- nathanwdavis 15y ago
  Genetics, cool!! Accounting for genetic drift must be a bitch though.
  - gokhan 15y ago
    Yep, generics, my bad.
- Jacob4u2 15y ago
  Even though I started this whole religious war thread, I don't really want to continue with it (but I'm too proud to delete my comment). Here is my rebuttal in a nutshell; VB is not succinct and therefore not a powerful language[1]. [1] http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html

yread 15y ago

> In C#, the modifier can be applied to a method, a lambda expression, or an anonymous method. In all other contexts, the term is interpreted as an identifier. Wow so you can have your cake and eat it! await is an accepted "keyword" but it's not actually a keyword as far as parser is concerned. Cool! I wish other compilers were this conscious of backwards compatibility.

lmkg 15y ago
C# has been pretty scrupulous about using contextual keywords instead of reserved keywords when they add new language features. That's why, e.g., they went with "yield return foo" instead of the more traditional "yield foo." They also let you define "var," which normally denotes type inference, as a normal type, and "var" will refer to the defined type in contexts where it is accessible.