Seems like this article conflates threads C# with asynchronous operations a little.

The way I see it, threads are for parallel & concurrent execution of CPU-bound workloads, across multiple CPU cores. And typically use Task Parallel Library. Async/await won’t help here.

Whereas async/await for IO bound workloads, and freeing up the current CPU thread until the IO operation finishes. As mentioned, syntactic sugar on top of older callback-based asynchronous APIs.

I would make the argument it does not matter what the intention is, in practice people await CPU bound tasks all the time. In fact, here is what the offical docs[1] say:

> You could also have CPU-bound code, such as performing an expensive calculation, which is also a good scenario for writing async code.

[1]: https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous...

The difference in philosophy is: who is responsible for scheduling work? Is it the language, or is it the developer?

In JS it's the language, for example node sits on top of libuv which is responsible for managing the thread pool and doing async IO.

The advantages of this system are that it's very convenient, and the developer gets a safer single-threaded view over the multiple threads in use. The disadvantage is that the developer lacks control and if you actually want to write multithreaded APIs and not just use them then you have to drop down into a lower level language so you can talk to libuv or the OS.

In C# there is no lower level language to drop down to.