| ▲ | the_mitsuhiko 6 days ago |
| You're probably right that this is leaning in on JavaScript and Python more, but I did try to make a point that the origin story for this feature is quite a bit different between languages. C# is the originator of that feature, but the implications of that feature in C# are quite different than in for instance JavaScript or Python. But when people have a discussion about async/await it often loses these nuances very quickly. > Async/await language feature introduced in .NET 4.5 in 2012 is a thin layer of sugar on top of these begin/end asynchronous APIs which were always there. You are absolutely right. That said, it was a conscious decision to keep the callback model and provide "syntactic sugar" on top of it to make it work. That is not the only model that could have been chosen. |
|
| ▲ | cwills 2 days ago | parent [-] |
| 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. |
| |
| ▲ | the_mitsuhiko 2 days ago | parent | next [-] | | 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... | | |
| ▲ | coldtea 2 days ago | parent [-] | | >You could also have CPU-bound code, such as performing an expensive calculation, which is also a good scenario for writing async code. That's a scenario for a different reason though (to allow sharing the cpu between chunks of the calculation, e.g. to not freeze UI in JS). In that case you might want to async on CPU-bound code. But regarding maximizing utilization, you want async to take more advantage of a core's CPU when you got tasks waiting for IO, and threads to leverage more CPU cores when doing CPU bound tasks. |
| |
| ▲ | zarzavat a day ago | parent | prev [-] | | 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. |
|
