It was my conclusion as well. I only found async useful in situations when a service has to deal with a large number of incoming requests, e.g. web server
> Anyway, this is much longer than I meant, but my conclusion is that I'll continue to use async/await for web apps and REST APIs (because, why not), but for services, I'm going back to the threadpool, green threads and synchronization primitives, and only using async/await in a limited way where it provides clear value - not async all the way down from the entrypoint.
AFAIK, .Net doesn't support "green threads" and they repeatedly confirmed that there are no future plans to do so. Additionally, M:N threading model has serious interop issues as evident in Go, which is a no-go for system languages. Personally, I don't see a need for green threads since kernel threads are fast enough and don't use that much RAM as people tend to believe. And when they are not, sure, go async/await.
Borland C++ and Turbo Vision were a killer combo back in the DOS times. Borland's decline over the years was painful to watch. I guess that what happens to the engineering driven companies that get overtaken by the MBA types.
Or, they are simply gaming H1B and/or employer-sponsored Green Card application process that requires submitting a proof that they couldn't find a US citizen.