Scala Actors: Unifying thread-based and event-based programming
blog.acolyer.org
Scala Actors: Unifying thread-based and event-based programming
1–10 of 19 posts
Re: Scala Actors: Unifying thread-based and event-based programming
#2TL;DR This is all the concrete code from the article:
1 awaitPing andThen sendPong
Re: Scala Actors: Unifying thread-based and event-based programming
#3I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
Re: Scala Actors: Unifying thread-based and event-based programming
#4I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe.
The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
Re: Scala Actors: Unifying thread-based and event-based programming
#5I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
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.
Re: Scala Actors: Unifying thread-based and event-based programming
#6I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
That was the immediately preceeding paper in the review series... http://blog.acolyer.org/2014/12/11/a-language-based-approach... !
Re: Scala Actors: Unifying thread-based and event-based programming
#7Earlier quoted context omitted.
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
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.
Having used STM in Haskell, actors look like a draconian way to handle shared mutable state.
Re: Scala Actors: Unifying thread-based and event-based programming
#8Earlier quoted context omitted.
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
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.
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.
Re: Scala Actors: Unifying thread-based and event-based programming
#9Earlier quoted context omitted.
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.
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.
Re: Scala Actors: Unifying thread-based and event-based programming
#10I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
How are you distinguishing 'distributed state' from 'local state'?