[bklimt]

The one advantage of C#'s async/await over Go's CSP is that by exposing the underlying Tasks, you can take more control over how the continuations get executed. The result of this is that it's easy to have async code that all runs on the same thread (usually the UI thread) even while it calls a function makes a network request that gets scheduled to a background thread.

Go's model doesn't give you as much control over which thread a particular operation gets assigned to. It's not theoretically impossible, I suppose, but it's hard to imagine what a simple API for it would look like.

But yes, if this particular problem were solved in an elegant way, I would also prefer the CSP model. It makes it so you don't have to worry about which operations are async or not.

[novaleaf]

A huge problem with C#'s Async feature that I hope gets resolved (and, obviously that this failure pattern is not ported to Javascript): Explicitly blocking during a function that uses async somewhere inside (a sub-function) will cause your application to deadlock. It is extremely surprising that .NET does not handle this (abet novice) design mistake in a graceful way. (For example, checking if a thread is blocked before attempting to schedule tasks to it)

[_wmd]

This was one of my main worries about Go when I evaluated it back in 2010. Most green threads implementations have an explicit determinism model, and it's typically straightforward to reason about and depend on execution order and suchlike, much as you can with plain asynchronous code, but with Go there didn't appear to be any guarantee when or how your code ran.

In any case I suppose many styles of Go program will exhibit accidental determinism, but it still seems too difficult to depend on as randomness can be introduced simply by invoking the wrong function, or by using a different runtime version, which to me feels comparable to the hazards of raw multithreading.