Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com