Hacker News Reader

Comment by d4nt | Hacker News Reader

I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their application into parallelizable chunks without ever really thinking about async or threads, they just just say "this web page is taking a long time to load, maybe I can defer some of the work until after the page load" or (as you seem to have done) "maybe I can use tools like AppFabric Workflow to orchestrate all these small tasks".

View on HN

When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case.

The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call finishes (i.e. consuming one thread from the connection thread pool). With async/await, the thread is released back into the thread pool until the result is ready, then it picks up where it left off.

So anything where you might want to deal with background operations that take a long time (including network / db / filesystem access, i.e. most applications that aren't pure functions) in a connection-oriented system can greatly benefit from async/await. Even if it's just a regular desktop app, it appears to be a useful mechanism for coordinating different background tasks.

Your point is a good one. Without wanting to get too deep into a design for some hypothetical system, I guess I was thinking that I'd either try and modify the current request such that it can return something to its caller (e.g. Render a web page saying "Loading..." with a setTimeout call in it). Or use .NET's HTTP request library which has a delegate callback option that lets you get on with other stuff.

One benefit to something like async/await is letting you get on with other stuff without having to murk up your code with callbacks/delegates which read more like GOTOs than async/await.

The problem with delegate/callback patterns with API calls is that you end up having to preserve a lot of state manually, which can be an error-prone process. Any metadata associated with a request must be persisted (and then read back) in painstakingly manual fashion with a delegate pattern, whereas with async (or closures, or...) this information is trivially available on your stack.

The nice thing about async vs. typical closures is that it neatly avoids a lot of nested scopes.

I was going to say the same thing. As a specific example I am currently working on a web application with multiple, complex views requiring several dropdowns. We noticed a dramatic speedup in these views when we refactored the controller to retrieve data for dropdowns using async/await.

The problem is that it's pretty useless in non-systems programming language.

It is pretty useful for ui stuff, you can start a wait cursor in a button event, do what you need to then put the cursor back when your done, all in one thread without having to use background threads or anything.

It is pretty simple for that scenario and avoids the cross thread marshalling you need to do in win forms.

Don't forget the SOA scenario: One service calls 0..n others to fulfill a request. Each of those calls is IO bound.

Reply on news.ycombinator.com