

Asynchronous Programming with Async and Await (C# and Visual Basic)  - fosk
http://msdn.microsoft.com/en-us/library/hh191443(v=VS.110).aspx

======
kogir
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
It looks like this functionality has been ported to node, have a look:
[https://github.com/koush/node/wiki/%22async%22-support-in-
no...](https://github.com/koush/node/wiki/%22async%22-support-in-node.js)

------
yread
> 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
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.

------
varunsrin
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
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>

~~~
varunsrin
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.

------
Jacob4u2
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?

~~~
gokhan
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
Genetics, cool!! Accounting for genetic drift must be a bitch though.

~~~
gokhan
Yep, generics, my bad.

