I'm inclined to agree with Chris, in the shared heap setting, you really should try those other approaches first! On Thu, Mar 27, 2014 at 2:32 AM, Christopher Allen wrote:

Have you looked at the Async library or Marlow's book?

http://hackage.haskell.org/package/async

http://chimera.labs.oreilly.com/books/1230000000929/

Neither involve actors but I think many Haskellers, myself included, are skeptical of actor/agent systems. I've written a fair bit of Clojure and Scala code and don't much care for the model.

If all you really need is message passing/dispatch, you don't strictly speaking need actors. Channels, messages, and dataflow might very well be enough. Perhaps look into functional reactive programming as well?

Cheers, hope this helps.

--- Chris

On Thu, Mar 27, 2014 at 1:29 AM, 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 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

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

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

On Thu, Mar 27, 2014 at 5:21 AM, Alois Cochard 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 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@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

the various "actor" libs are all different, and they make different trade offs, theres no "this is best" (yet). I'm personally unsatisfied with the solutions i've seen in haskell and other languages personally, so i'm sorely tempted to yak have my own and thus contribute to the confusion even more :) On Thu, Mar 27, 2014 at 5:40 PM, james wrote:

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

On Thu, Mar 27, 2014 at 5:21 AM, Alois Cochard wrote: 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 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@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

@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

On Thu, Mar 27, 2014 at 5:21 AM, Alois Cochard wrote: 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 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@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

Thanks Alois, I have recently been using Cloud Haskell for multi-machine programs.

i've written both haskell and erlang professionally, and never had a need for actors/message passing

Even though Tom made a mention of distributed-process, part of Cloud Haskell, I wanted to find out if their were other viable approaches to distributed computing being explored by the Haskell community. Patrick On Fri, Mar 28, 2014 at 6:39 AM, Alois Cochard wrote:

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

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

For throughput base stuff, a careful mix of Some of the libs and tools that simon marlow espouses in his lovely book will get you very far. Which is very different from actors models as folks here will assume you mean. So just use asynch, monadpar, Ryan newtons concurrency libs, and a few other things. Ghc itself has a work stealing scheduler deque for sparked computations! On Friday, March 28, 2014, james wrote:

(Isn't it nice to be on a list where peopel top-post? ;-))

Actually I already have Haskell-like code at work where I have actor-like processing with (event, state) -> (state', actions) and these are mostly pure. And I like the model.

I'm NOT looking for spreading over boxes. What I'm interested in is optimisation of the flow of control: - if an actor has a deep queue of input events, I want it to spin in-cache efficiently. - if an actor makes an RPC-like transaction against a dormant peer, then I want the flow of control on the bound thread to go from one to the other and back, and not result in general scheduling - I want the performance of general messaging to be somewhat like that of the work-stealing pool we see working well in Akka and JActor

I would be surprised if general LWP scheduling will really be up to it, in terms of competing, particularly in the case of RPC interactions or pipelines where we'd really want to stay cache-hot for either the code (for an actor spinning on a deep queue) or the data (for a pipeline or RPC).

I'm also interested in terms of how a channel can effectively (and efficiently) handle messages where the channel is carrying a union of message types that can evolve as the system is built.

I'm quite happy to do explicit networking between processes in different NUMA zones or on different hosts.

James

(Not made my mind up about Erlang - I really like per-actor GC tho. Will try to play with Nimrod sometime)

On 27/03/2014 22:34, amindfv@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

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