It was started with C# 5's new keyword "async". And now I see this async programming everywhere from Javascript to C++, mostly from Microsoft. And from various discussions I came to know, this is a very useful technique to avoid threading yet keep CPU working while other things are fetched form hard disk or network.

My question is, why such an important topic was ignored all these days? Or it's just a hype from Microsoft?

Have you looked into the history of concurrent programming? I think this kind of stuff has been around a long time though you may not have seen it unless you knew what you wanted to see about it.
–
JB KingJul 8 '11 at 18:24

Uh... it wasn't even ignored by Microsoft before C# 5. Async patterns based on delegates and IAsyncResult have been in the framework since I think 1.1 (maybe 2.0), as have async pages in ASP.NET. Many if not most of these are based on thread pools and I/O completion ports, which have been in the Windows operating system for, like, forever.
–
AaronaughtJul 8 '11 at 19:02

Although they are promising to extend node.js to a multi-process model. While it may give you an asynchronous programming model it cannot take advantage of multiple processors, hyperthreading, etc.
–
JeremyJul 8 '11 at 18:40

@Jeremy Of course it can. Run multiple node instances. There's a child process API you can hook into. Rather then doing multi-processing using "method X" by default, node gives you the flexibility to handle it however you want.
–
RaynosJul 9 '11 at 10:19

You do realize the first A of AJAX is Asynchronous, right? That is one source of it for the past decade. Multi-core CPUs may be another reason for some of this as more threads can be handled at once the problem of synchronization which has been around for a while, see Two Generals' Problem which had a proof written in 1975.

A number of people have asked me "so
does this mean that the Task
Asynchrony Pattern only works on UI
threads that have message loops?" No.
The Task Parallel Library was
explicitly designed to solve problems
involving concurrency; task asynchrony
extends that work. There are
mechanisms that allow asynchrony to
work in multithreaded environments
without message loops that drive user
interfaces, like ASP.NET.

Thus points on concurrency are relevant here. If you want to suggest that isn't the case, please back up that argument as concurrency seems relevant here. I will concede that Asynchrony isn't exactly concurrency.

Looks similar to what some Lisp dialects call futures, although the syntactic restriction (plus some of the discussion links) imply that they're doing it via a local CPS (continuation-passing style) transformation.

As to why it's taken so long, if you come from a C/C++ mindset, you probably think "the stack" is real; you expect variables to live there, you might even create pointers to stack-allocated things. Whereas in a higher-level language, you think about the program context (or continuation), which might live on "the stack", but might be copied or moved when the language runtime feels like it to implement things like first-class continuations, lightweight threads, deep recursion, and proper tail recursion on unfriendly platforms. It sounds like .NET is just taking some of the techniques developed for implementing higher-level languages and bringing them, conservatively, into C#.

Multiple cores have made it async a much more useful language feature. Instead of being merely a way of easily swapping out tasks, it is an easy way to have multiple tasks going on at the same time. The greater value has lead to greater use.

Plus from a marketing point of view, you have to have something radically new when releasing a new version of a product. :)