Asynchronous Programming with Async and Await (C# and Visual Basic) | Hacker News Reader

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

msdn.microsoft.com

67 pointsfosk18 comments

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

It looks like this functionality has been ported to node, have a look: https://github.com/koush/node/wiki/%22async%22-support-in-no...

See this comment from MostAwesomeDude in a different thread:

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

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

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

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.

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

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

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/hh46492...

I think that's because the TPL doesn't exist for C++.

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.

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?

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.

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.

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 :)

Genetics, cool!! Accounting for genetic drift must be a bitch though.

Yep, generics, my bad.

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

Succinctness is definitely not the sole measure of programming language's power. If it was then APL would have become mainstream. In that case it actually worked against adoption of the language even though it was very capable otherwise.

Reply on news.ycombinator.com