
Scala Actors: Unifying thread-based and event-based programming - tambourine_man
http://blog.acolyer.org/2014/12/12/scala-actors-unifying-thread-based-and-event-based-programming/
======
pacala
TL;DR This is all the concrete code from the article:

    
    
        1 awaitPing andThen sendPong
    

I'd find more valuable blog posts explaining how to solve a concrete problem
with concrete code using the Actor model than mishmashes of quotes appealing
to various authorities.

~~~
lomnakkus
I was going to chide you for unfairly calling out the lack of code vs. the
abundance abstract concepts, but... yeah. This was pretty much content-free
except for a few links to... things.

~~~
pacala
I'm working hard to keep a professional, factual approach. There is more under
the surface:

A. (Appeal to authority) Until very recently, I've worked for years at a huge
and very successful distributed systems company. There wasn't a single system
using the actor model I ran into. I haven't heard anyone advocating for the
actor model. Everything was a service with an RPC interface. At least one
other huge competitor is well known for a service-oriented revolution phase.

B. (Unsubstantiated anecdote). The majority of advocacy around Actors I've
come across lacks substance. There is very little exemplification of what
problems are solved or comparison to other ways to solve the problem. But it's
almost guaranteed to have an appeal to Erlang's authority thrown somewhere in
there. The OP is a canonical example.

C. (Concrete example, you can start calling me out on it). Speaking of actors,
messaging and distributed systems, I just don't get what's the point of
sending an unreliable message if you don't check the response and tailor your
reactions based on it. Which is basically doing RPCs. How do you even test
something like "endpoint.send(request)" when messages can get lost?!

Sorry if I sound harsh and unfair. I only bring this up because I'm forced by
exterior circumstances to pay attention to "Actor model" tradeoffs.

~~~
lomnakkus
I think you misunderstand. I was (at least in substance) agreeing with you! :)

The operative phrase being "I was _going to_..." [but didn't].

EDIT: ... but awesome post nonetheless! ;)

------
strmpnk
I find this paper on an approach for Haskell much more interesting:
[http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf](http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf)

~~~
lomnakkus
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.

~~~
saryant
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.

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

~~~
lomnakkus
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.

~~~
DanWaterworth
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](https://hackage.haskell.org/package/blocking-transactions)

