News for hackers. Stuff that matters.

A comment on Scala Actors: Unifying thread-based and event-based programming. Parent comment

Re:Scala Actors: Unifying thread-based and event-based progr... by saryant on Sunday January 11, 2015 @02:21PM (#8870925)
Actors aren't just about distributed state, they're about any state that could be accessed or modified concurrently. Distributed systems don't have to come into play for actors to be useful. Actors provide a sane way to deal with mutable state with potentially multiple readers or writers.
[ Parent | on HN ]
Re:Scala Actors: Unifying thread-based and event-based progr... by lomnakkus on Sunday January 11, 2015 @03:44PM (#8871219)
Any state that could be accessed or modified concurrently is effectively distributed (in the Actor model). (If not over the network, then over multiple CPUs communicating over a bus which may require memory barriers.)

Unfortunately the model mandates that you must either a) implement ALL of your cohesive/non-concurrent state in "one actor per unit of cohesion" or b) deal with state as if it's distributed.

In other words: It's not a good tradeoff for typical programs. (Which I think is what my original comment said.)

Don't get me wrong: If almost all your state is distributed, e.g. Riak, then I'm sure it's a fine way to do things. Let's just avoid the "works-for-them-It's-sure-to-work-for-us" pitfall.

[ Parent | on HN ]
Re:Scala Actors: Unifying thread-based and event-based progr... by DanWaterworth on Sunday January 11, 2015 @03:09PM (#8871091)
Having used STM in Haskell, actors look like a draconian way to handle shared mutable state.
[ Parent | on HN ]
Re:Scala Actors: Unifying thread-based and event-based progr... by lomnakkus on Sunday January 11, 2015 @03:48PM (#8871237)
Exactly!

Unless you're hitting actual trouble with contention (or some such), there's absolutely no reason to be programming as defensively as we must do in distributed systems.

[ Parent | on HN ]
Re:Scala Actors: Unifying thread-based and event-based progr... by DanWaterworth on Sunday January 11, 2015 @04:26PM (#8871387)
If you have problems with contention, you can use a library like this [1], that allows you to perform transactions (with the restriction that you must know the variables you may touch ahead of time) without deadlocking or livelocking.

[1] https://hackage.haskell.org/package/blocking-transactions

[ Parent | on HN ]