Re:.NET 5.0
by cm2187 on Tuesday November 10, 2020 @12:18PM
(#25048373)
Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dealing with a UI and make a method async, then suddenly you have a ton more problems to deal with, like what happen if the user changes the state while you are waiting for an async call. That increases a lot the complexity of the code. Which is why I am lukewarm about their approach of mandating async for new features.
[ Parent
| on HN ]
Re:.NET 5.0
by asyncawaaait on Tuesday November 10, 2020 @02:27PM
(#25050452)
How does async/await introduce complexity where threading wouldn’t?
In my experience, the complexity is vastly reduced by not having to implement tricky asynchronous APIs (Task Paralell, thread pools, BackgroundWorker, etc).
no, vs blocking the UI thread. Which is perfectly fine the vast majority of the cases, unless you are running something long running.
You are trying to something slightly complex. I don't see how one could make it any easier from a language design perspective and staying idiomatic to the language.
Go: Goroutines make you wire the "stop" scenario on your own (channel close). Rust: Hold on to your future and drop() it. C#: Pass a cancellation token and call Cancel()
All seem reasonable and stay within what they think their developers will be able to pick up and run with.
Re:.NET 5.0
by spaetzleesser on Tuesday November 10, 2020 @01:57PM
(#25049813)
Agreed. Async is nice on the server but on the desktop it’s a real problem. For a while they had both sync and async but now it’s often only async.
I just finished an app that had to shutdown while some async operations were still not finished. Really hard to manage compared to using threads.
How is Task.WaitAll different from Thread.Joining a bunch of threads? Or if you were cancelling tasks, using cancellation tokens?
The other comment alluded to this, but the crux of the problem is that you can schedule a task to run and wait on the completion of that task, but the only available thread for it to run is the one currently waiting for it to complete. The writeup here isn't bad: https://devblogs.microsoft.com/pfxteam/await-and-ui-and-dead...
If you are running Task.WaitAll on a UI thread you are likely to create a deadlock.