
Ha4: Concurrent ML and HOPAC - mpweiher
http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.html
======
xyz-x
I've started writing code in Hopac after reading the red Reppy book and the
awesome
[https://github.com/Hopac/Hopac/blob/master/Docs/Programming....](https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md)
-guide. It's really neat.

------
ZenoArrow
Wasn't aware of Hopac before, just done some digging around online, these
benchmarks look fairly impressive:

[http://vaskir.blogspot.co.uk/2015/01/fibanacci-hopac-vs-
asyn...](http://vaskir.blogspot.co.uk/2015/01/fibanacci-hopac-vs-
async.html?m=1)

Are there any downsides to using Hopac over one of the other .NET concurrency
libraries?

~~~
xyz-x
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
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.

------
transfire
Wooh. That [HOPAC
API]([http://hopac.github.io/Hopac/Hopac.html](http://hopac.github.io/Hopac/Hopac.html))
is ginormous! How can anyone seriously code with that?

~~~
eyelidlessness
What's with the awful font and seriously slacker half attempt at alignment? I
basically can't read anything on that page.

~~~
polytypic
Thanks! I removed the bold attribute from links so things should align better
now on some browsers.

~~~
eyelidlessness
1\. That helps a lot!

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.

~~~
polytypic
No problem.

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.

------
zzzcpan
> 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.

~~~
xyz-x
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.

~~~
zzzcpan
That was the point, you can't have something reliable and performant in a real
world if you use a bounded model for it [world].

~~~
xyz-x
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.

