I used async for a WPF application. That worked out well. I also experimented with a scraper using async. I dug myself into holes very quickly (memory usage

I used async for a WPF application. That worked out well. I also experimented with a scraper using async. I dug myself into holes very quickly (memory usage ballooned, difficult to debug and reason about application state despite the code being very easy to read, threads were being created all over the place which annoyed me even though I understood why). I rewrote the scraper to use BlockingCollections and Take(), with async being used solely with the HttpClient (which really needs to learn how to play nicer with async in the face of network errors!). The code was more decoupled, and while slightly more difficult to follow because of this, far easier to test and debug because the working set of my application was explicit rather than hidden in tasks. This had the added benefit of making it easy to persist and restore state. For me, the concurrent collections introduced in .NET 4 have been the big winner (no more custom thread pools!). Use of async needs to be matched carefully with the problem domain, especially in backend development.