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.
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.
2. The alignment still leaves a lot to be desired. There's stuff that is clearly intended to align that doesn't, and it's more distracting than if it didn't attempt to align at all.
3. I apologize for the insulting way my previous comment was written. I try not to do that; I must have been grumpy, but it's no excuse.
There were still some bolded elements, so I switched to a different color scheme and further removed bold elements.
Looking through the doc I can't spot any cases where alignment would be unintentionally wrong. I think the next thing to do to improve readability would be to add some spacing around groups of definitions. This way different alignments used in side-by-side groups should cause less visual interference. I suspect that the visual interference from side-by-side groups is what makes the alignment look distracting.
> would "help fight actor/reactive nonesense" and was asked to elaborate
So, basically fighting actors with channels and synchronous selective operators, right? This is not how it works, because bounded nondeterminism is precisely what actor model was trying to get away from.
I had to read up a bit on (un-)bounded non-determinism there. It would seem actors give you even looser safety properties in that it has unbounded non-determinism and you can't really sure about anything about your programming model in the default case.
I'm actually don't agree at all to this. Is e.g. the MillWheel software, or Kafka, or Storm/Spark inherently unreliable and non-performant because they feature strong consistency and bounds on their operations? I don't think so.
