Let me make clear that i agree with you... if you look at java solutions to
those issues .. they are complete inellegant and almost force you to
deadlocks or bad performance using locks (coming back to single threaded
performance)...
so actors are far way better then the usual approach...
the thi
On Sun, May 16, 2010 at 3:19 PM, Fabio Kaminski wrote:
> Sorry about using the list like twitter..
>
> but i thought this is a pretty good "article" about functional programming
> side effects, and why actors are not very good design decision..
>
> Actors not good for concurrency model :
>
> http:
> I'm not sure why a getValue/setValue is any different from an ='s
> sign. Instability and unpredictability still results. Be they actors
> or threads, neither really solves any sort of problem save perhaps
> atomic updates.
My (unproven) gut feeling is that people are afraid of machine
concurren
On Mon, May 17, 2010 at 11:20 PM, Peter Schuller
wrote:
>> Actors in Erlang DO have mutable state, you're just discouraged from
>> using it. ;) No really, erl -man get and set. Sometimes you're forced
>> to use this despite the best of intentions.
>
> I don't think anyone is trying to claim that i
> Actors in Erlang DO have mutable state, you're just discouraged from
> using it. ;) No really, erl -man get and set. Sometimes you're forced
> to use this despite the best of intentions.
I don't think anyone is trying to claim that it is impossible to
mutate shared in state in an erlang actor. T
> i don't expect it would be hard to write an Erlang program with 2
> actors that would deadlock.
Of course it wouldn't.
> as far as i know, people use timeouts on
> message handling to sweep it under the carpet.
Most people probably use the OTP library with well-defined "behaviors"
is what they
Actors in Erlang DO have mutable state, you're just discouraged from
using it. ;) No really, erl -man get and set. Sometimes you're forced
to use this despite the best of intentions.
But I really have to ask, how composable were monads again?
- dlf
On Mon, May 17, 2010 at 3:04 AM, Peter Schuller
> i don't expect it would be hard to write an Erlang program with 2
> actors that would deadlock. as far as i know, people use timeouts on
> message handling to sweep it under the carpet.
>
> e.g. (just a quick google search turns this up)
> http://mue.tideland.biz/avoiding-erlang-deadlocks
So yes
On Mon, May 17, 2010 at 3:04 AM, Peter Schuller
wrote:
> Deadlock in a message passing system is still possible if you limit
> the mailbox size (unless some other means are used to prevent it). My
> understanding is that mailbox size is not limited in erlang, and that
> there is no other means to
> far as i know..actors share a mutable queue.. so there's good possibility
> for dead-locks
Actors as they work in erlang don't have mutable state (not
intrinsically anyway, though of course you can implement an actor that
does poke on shared data since it's your code). The 'state' in an
erlang a
far as i know..actors share a mutable queue.. so there's good possibility
for dead-locks
for scala theres an akka framework , that you can solve that with its actors
.. that let me see.. uses a STM..
and its actors are pretty the same as .. clojures agents
i think clojure are making disciples in
Nice diatribe against actors by someone who's apparently never...
actually... used... actors. Clojure is really nice, but that doesn't
mean I'm going to buy into weak arguments against features it doesn't
have in its core.
On May 16, 12:19 pm, Fabio Kaminski wrote:
> Sorry about using the list l
12 matches
Mail list logo
