3 ms·

It's a different programming model that you'll have to learn. It will take you a week or two to become proficient. It's not mainstream but instead based on a ti

by xyz-x 10y ago

It's a different programming model that you'll have to learn. It will take you a week or two to become proficient. It's not mainstream but instead based on a time-tested abstraction. The docs are top notch when you include the book, but they are not spread out over multiple sources. It's doing cooperative multi-threading, so if you have software that doesn't want to cooperate you may experience problems with fairness. It's [pull-based/cold/sync/rendezvous based], not [push-based/hot|cold/sync/scheduler-oriented] (rx), not [pull-based/cold/async/non-deterministic] (F# async), not [pull-based/hot/async/non-deterministic] (TPL) so you'll have to start thinking about what concurrency and parallelism means for you.

Matthias247 10y ago
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.

by xyz-x 10y ago

Matthias247 10y ago

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.