Everything .NET programmers know about Asynchronous Programming is wrong (hanselminutes.com)

Take out all that complicated code, and replace it with a call to an external 3rd party API. They get a hiccup, your response time goes up by 500%, your cpu load drops, and you start timing out connections.

C10M http://www.youtube.com/watch?v=D09jdbS6oSI

Where the async syntax really shines is dealing with external services. If you're calling a lot of database, web services, sockets etc it can make your life easier.

If you have 80,000,000 machines serving 80,000,000 requests - that's not very impressive. Even if you have 80 servers, that's extremely unimpressive.

If you can do all of that on 1 server, then YOU probably don't need async. In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/second, and peak is likely less than 100 requests/second. That's really not much - I do that with interpreted python.

But every language does need facility for async processing.

edit: it's 1000/second, not 10/second, as everyone down here corrected. Apparently, I cannot math before coffee. (I don't drink coffee). Apologies.

fun mnemonic: the number of seconds in a day is 864e2. (eight-six-four-(e)-two).

Or even delegates. Or interfaces. Or LINQ.

Basically you could write the same thing in C.

Or assembly.

But it's a big leap to go from that to saying that nobody else needs async, so it need not go in the language.

[1] Taking the calculation off the main thread isn't the only way async can help here. The primitives also give you a way for taking better advantage of multiple cores (futures) more easily.

I too have applications that do a lot of stuff relying of asynchronous toolsets but without much explicit asynchronicity. However, I did a simple experiment a couple weeks back - I coded one of our simple but very asynchronous programs in Go. Compared to the Python original (which uses Twisted), the Go version had 70% of the lines and was much more readable and understandable by even team mates who had never seen Go.

I believe that's the point of having async operation elegantly merged into the language.

A better question is how many lines of code the async feature saves, compared to the code you would write without it.

It's about doing more, better, and easier. async allows a pretty complicated process to be much easier to write.

To appreciate async and await, you have to go through the exercise of converting some synchronous code to an event driven model with callbacks. Then do it using async/await. It's more syntactic sugar than anything.

I appreciate it in how I appreciate the dynamic keyword. I know how to dynamically Invoke() methods at runtime using reflection. It's a lot of boilerplate and ceremony, and the dynamic keyword helps alleviate that.

Just a few weeks ago I was able to convert a nightmare-ish recursive asynchronous method to a `foreach` loop with `await`s inside.

It's cool when you can do this:

    var providerExceptions = new List<Exception> ();

    // Try each provider in turn
    foreach (var pi in providers) {
        token.ThrowIfCancellationRequested ();

        try {
            return await GetSession (provider, isLast, options, token);
        } catch (TaskCanceledException) {
            throw;
        } catch (Exception ex) {
            providerExceptions.Add (ex);
            // Fall back to next provider
        }
    }

    // Neither provider worked
    throw new AggregateException ("Could not obtain session via either provider", providerExceptions);

    async Task<Session> GetSession (AccountProvider provider, bool isLast, LoginOptions options, CancellationToken token)
    {
        if (!SessionManager.NetworkMonitor.IsNetworkAvailable)
            throw new OfflineException ();

        var account = await GetAccount (provider, !isLast, options);
        if (account == null)
            throw new Exception ("The user chose to skip this provider.");

        var service = provider.Service;
        var session = new Session (service, account);

        if (service.SupportsVerification) {
            // For services that support verification, do it now
            try {
                await service.VerifyAsync (account, token);
            } catch (TaskCanceledException) {
                throw;
            } catch (Exception ex) {
                throw new InvalidOperationException ("Account verification failed.", ex);
            }
        }

        return session;
    }

Second note: If your app has lots of short-ish lived requests, you can just achieve parallelism by having a decent-sized threadpool and just run each request on a thread. Who cares if you have 400 threads? It'll scale well enough (as you noticed).

However, if the app is doing long-running requests/clients, and you dedicate a thread to each one, then you end up with a lot of extra overhead. Using C#'s async model can simplify the code while keeping things lightweight.

This isn't the only way to increase concurrency. Obviously you can grow your IIS web farm as well. But async/await (or some other .NET asynchronous programming pattern[1]) is a one-time .NET development cost as opposed to a recurring infrastructure/hosting cost.

[1] http://msdn.microsoft.com/en-us/library/jj152938.aspx

How would you implement Observable.LastAsync, without using something equivalent to TaskCompletionSource along the way?

If you could define a method as async and then call it either syncronously or not the whole point of the async keyword is lost. You would end up with the compiler doing a load of work because every developer will just slap async on every method just in case rather than actually thinking about what needs to be async and what doesn't.

Adding the async keyword is not a magic bullet, there's a huge amount of work going on under the hood every time you use it and it's important that developers appreciate that.