4 ms·
Strongly agree. Honestly, just the first point "Asynchrony is viral" is a huge fucking flag that this implementation sucks. It doesn't need to be viral, they
by horsawlarway 5y ago
Strongly agree.
Honestly, just the first point "Asynchrony is viral" is a huge fucking flag that this implementation sucks.
It doesn't need to be viral, they just needed to make passing a continuation easy, and they failed miserably.
Overall - I really like most of C#, but that async/await implementation is poor at best.
- torginus 5y agoI thought about this for a while as well, especially as I'm both a Go and .NET programmer, and made the following observation: Go and .NET have something that's viral about their IO code. In Go's case it's errors, in .NET's case it's async. Then I realised that basically all code that is async in .NET is I/O code just like all code in Go that throws runtime errors is I/O code as well. This is not a perfect heuristic, but it works 95% of the time. Which means that .NET code tends to suffer from the same issue as Go code. The solution is the same as well: Separate out the code that does logic processing from the code that does I/O. This way only a few top level functions will become async. I find that this makes my code cleaner and more testable as well.
- CuriousSkeptic 5y ago> Go and .NET have something that's viral about their IO code. This is basically what some language communities are trying to capture with “monads” (like “the IO monad”) There are some work yet on how to make such representations compose[1] (like how IEnumerable + Task = IAsyncEnumerable) but eventually we’ll probably see some form of effect systems for all such things reach mainstream languages. [1] http://okmij.org/ftp/Haskell/extensible/more.pdf http://okmij.org/ftp/Haskell/extensible/more.pdf