Re: [Haskell-cafe] Best Actor system?

As mentioned before, there is Cloud Haskell: http://www.haskell.org/haskellwiki/Cloud_Haskell On 27 March 2014 23:22, Patrick Wheeler wrote:

@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, 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 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 wrote:

...

Can anyone give some detailed cons of Akka / actor model?

...

I have good experience with actors (Scala/Akka), and I can tell 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 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

On Thu, Mar 27, 2014 at 5:21 AM, Alois Cochard wrote: that you 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@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Patrick Wheeler Patrick.John.Wheeler@gmail.com Patrick.J.Wheeler@rice.edu Patrick.Wheeler@colorado.edu

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard