Hacker News Reader

Comment by saryant | Hacker News Reader

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.

View on HN

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.

Having used STM in Haskell, actors look like a draconian way to handle shared mutable state.

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.

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

Reply on news.ycombinator.com