[Haskell-cafe] Best Actor system?

[amindfv at gmail.com]

Unfortunately I can't help with recommending an actor library. I think peoples' responses of "you should never want to do that" are, um, unhelpful.

That said, i've written both haskell and erlang professionally, and never had a need for actors/message passing in haskell. It may be the wrong tool for most haskell jobs.

The main things erlang-style concurrency gets you are
 - lightweight threads (in haskell by default -- 'forkIO' creates lightweight threads)
 - limited shared mutable state (haskell's pure)
 - spreading computation over cores (in haskell you want parallelism not concurrency -- check out the Par monad)
 - computation over boxes (see distributed-process)

To do "message passing", check out MVars (and later, STM)

Tom


El Mar 27, 2014, a las 17:40, james <james at mansionfamily.plus.com> escribió:

> On 27/03/2014 17:28, Christopher Allen wrote:
>> I don't actually want to get drawn into this, but one point would be that it's really just the same fallacies as OOP in general, but concurrent.
> 
> Well, horses for courses, I've been writing distributed C++ apps since cfront was shiny and new.
> 
> I find writing off OOP as distasteful as writing off functional, and there are people in both camps.
> 
> I have ordered Simon's book and will take care to read it.
> 
> In the mean time - does anyone have an answer to the question I asked?
> 
> James
> 
>> The idea that isolation behind an interface (message passing or not) is going to prevent unnecessary mutation or side effects from getting out of control.
>> 
>> In practice, it doesn't do that at all and the fact that you're making your inter-dependencies more implicit, rather than explicit, through the use of isolated buckets of side-effecting state and mutation is going to make it harder rather than easier to debug the program when it invariably             breaks. I'd rather get a call-stack if I'm going to abandon Haskell-y goodness. And your Actors *will* get into a bad state, so you'll end up writing Inspector and Debugger mixins just to keep a handle on the complexity when they get into that bad state.
>> 
>> It's not impossible for Actors to make sense. I used agents (which are not full-blown Actors per se) in Clojure for side-effect isolation, serialization, and thread safety to good effect, but I kept how much "work" they did to a bare minimum and tried to keep everything in pure functions as long as I could.
>> 
>> It's just that I see programmers with a shiny new hammer looking for every nail they can find.
>> 
>> 
>> 
>> On Thu, Mar 27, 2014 at 12:21 PM, Zongheng Yang <zongheng.y at gmail.com> wrote:
>>> Can anyone give some detailed cons of Akka / actor model?
>>> 
>>> On Thu, Mar 27, 2014 at 5:21 AM, Alois Cochard <alois.cochard at gmail.com> wrote:
>>> > I have good experience with actors (Scala/Akka), and I can tell you that you
>>> > should avoid them as much as possible.
>>> > I think the model is good if you need to do some low level concurrency
>>> > coding on a language that don't have effect tracking in types.
>>> >
>>> > Having used the Async library from Marlow, I highly recommend it... and it
>>> > probably cover a big percentage of traditional concurrency use cases.
>>> >
>>> > You still have Haskell Cloud if you want distributed messaging.
>>> >
>>> > Cheers
>>> >
>>> >
>>> >
>>> > On 27 March 2014 06:29, james <james at mansionfamily.plus.com> wrote:
>>> >>
>>> >> Having been introduced to actors by looking at Erlang, I discovered Akka.
>>> >>
>>> >> It seems that the performance is pretty impressive and I like the model.
>>> >>
>>> >> There seem to be several basic Actor libraries in Hackage, but they don't
>>> >> seem
>>> >> to be very actively developed.
>>> >>
>>> >> I'm more interested in the model for programming within a single runtime
>>> >> than I am for distributed systems, but message and dispatch performance
>>> >> definitely is important.
>>> >>
>>> >> Can anyone share experiences with the different packages?  Is any one
>>> >> of them stand-out?
>>> >>
>>> >> Thanks
>>> >> James
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Haskell-Cafe mailing list
>>> >> Haskell-Cafe at haskell.org
>>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Alois Cochard
>>> > http://aloiscochard.blogspot.com
>>> > http://twitter.com/aloiscochard
>>> > http://github.com/aloiscochard
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140327/58aed953/attachment.html>