Comment by neonsunset
Comment by neonsunset 2 days ago
I suppose the difference of opinion comes down to whether you consider hiding side effects a good or a bad thing. And whether you want to have easy composition and cancellation (Go struggles with passing context around a lot, in .NET it's much less of an issue if at all, depending on codebase).
If you don't want to join on some other virtual thread or goroutine completing immediately (and with Goroutines it's additionally painful since you need to communicate completion separately), it's more difficult and costlier than doing so with tasks/futures.
CancellationTokens can be passed in synchronous functions just fine, I have done cancellable sync apis before cancellation tokens existed usually its a .Cancel() on the thing doing the work just like Command.Cancel() in the Sql client or Connection.Cancel() in a network client. I agree CancellationTokens are better and always use them now and thats not the problem with async.
The problem is the need to color functions with async and if you have existing client code that call existing synchronous methods it not easy to move their internal implementations to async form so that you can remain backward compatible without copy/pasting the same layers of code with different function coloring to async.