[Haskell-cafe] Best Actor system?

[Patrick Wheeler]

@tom - forkIO and freineds works great for lightweight local threads, what
about non-local threads though in a distributed setting.  Is there anything
in haskell that you think replaces that functionality in erlang?


On Thu, Mar 27, 2014 at 10:34 PM, <amindfv at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Patrick Wheeler
Patrick.John.Wheeler at gmail.com
Patrick.J.Wheeler at rice.edu
Patrick.Wheeler at colorado.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140327/c3a6a598/attachment.html>