I agree with that. Played a little bit with Hopac (after also using anything from TPL, F# async, Rx, ...), and I think it's quite awesome. However it takes some

I agree with that. Played a little bit with Hopac (after also using anything from TPL, F# async, Rx, ...), and I think it's quite awesome. However it takes some time to get into it, and the monadic expressions and all those operations really take some time to learn and are not as easy to understand as e.g. Go's inbuilt concurrency primitives. For that reason I don't think Hopac will become mainstream. However it's very powerful, probably more powerful than any often the other things. And the performance is also excellent. Some other ultra-short comparisons to the other concurrency approaches: - The rendezvous model with bounded channels is IMHO the best communication model for resource passing between different "actors", as you can avoid situations were you pass a resource but nobody listens for it any more. - Hopac (like Go) provides selective communication, which is very helpful for implementing some kind of stuff as explained in the Hopac documentation (and avoiding weird "try two things and cancel the second one later workarounds"). - Hopac is a lot faster then F# async according to my benchmarks. C# async/await with good TaskScheduler implementation can however reach a similar performance level. - Rx has probably the most event combinators. I think it's nice for event processing in some scenarios, e.g. UI events. - The pull based approaches of TPL, F# async and Hopac provide more explicit flow control (and thereby backpressure) as the push based approach of Rx. I personally wouldn't use Rx anymore for anything where flow control is important. But this is only my taste, the newer Rx versions also provide some backpressured stream support.