Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Actors: Unifying thread-based and event-based programming

blog.acolyer.org

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Scala Actors: Unifying thread-based and event-based programming

#11

Post by DanWaterworth »

lomnakkus wrote: post #9
DanWaterworth wrote: post #7

Earlier quoted context omitted.

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

Re: Scala Actors: Unifying thread-based and event-based programming

#12

Post by lomnakkus »

lostcolony wrote: post #10
lomnakkus wrote: post #4

Earlier 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.

How are you distinguishing 'distributed state' from 'local state'?

I'm not sure what you're asking. We do that by designing our programs in certain and deliberate ways. Does that answer your question?

EDIT: I suppose I should expound a little: It's not as if state is being thrown at us from random corners of the world. Our programs have inputs (which may be noisy, messy, distributed, fragmented or whatever), but that doesn't mean that we "cannot possibly know" what those inputs are. We can actually codify the uncertainties of our inputs -- which grants us even more power!

Re: Scala Actors: Unifying thread-based and event-based programming

#13

Post by lomnakkus »

pacala wrote: post #2

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.

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.

Re: Scala Actors: Unifying thread-based and event-based programming

#14

Post by pacala »

lomnakkus wrote: post #13
pacala wrote: post #2

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.

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.

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.

Re: Scala Actors: Unifying thread-based and event-based programming

#15

Post by lomnakkus »

pacala wrote: post #14
lomnakkus wrote: post #13

Earlier quoted context omitted.

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.

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…

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! ;)

Re: Scala Actors: Unifying thread-based and event-based programming

#16

Post by lostcolony »

lomnakkus wrote: post #12
lostcolony wrote: post #10

Earlier quoted context omitted.

How are you distinguishing 'distributed state' from 'local state'?

I'm not sure what you're asking. We do that by designing our programs in certain and deliberate ways. Does that answer your question? EDIT: I suppose I should expound a little: It's not as if state is being thrown at us from random corners of the world. Our programs have inputs (which may be noisy, messy, distributed, fragmented or whatever), but that doesn't mean that we "cannot possibly know" what those inputs are.…

I don't know what you mean to distinguish by using the terms 'local state' vs 'distributed state'.

Local state...does that mean state that is local to a process? Local to a machine? Something else entirely?

Distributed state, does that mean any state not encompassed by the prior definition (state on another process, another machine, etc, than the one we're currently talking about)? State that is implicit in the system (i.e., whether an event/message was sent, or not)? State being passed around as part of the event/message?

EDIT: I guess my main question is this - are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'd buy that.

The assertion you make of "It's not a good tradeoff for typical programs" requires me to understand what that tradeoff -is- when you describe distributed vs local. It sounds more like local vs global state. And what do you mean by 'typical'? Just, the way things will naturally be written by someone coming from an imperative, locking language? Or something else.

Etc.

Re: Scala Actors: Unifying thread-based and event-based programming

#17

Post by lomnakkus »

lostcolony wrote: post #16
lomnakkus wrote: post #12

Earlier quoted context omitted.

I'm not sure what you're asking. We do that by designing our programs in certain and deliberate ways. Does that answer your question? EDIT: I suppose I should expound a little: It's not as if state is being thrown at us from random corners of the world. Our programs have inputs (which may be noisy, messy, distributed, fragmented or whatever), but that doesn't mean that we "cannot possibly know" what those inputs are.…

I don't know what you mean to distinguish by using the terms 'local state' vs 'distributed state'. Local state...does that mean state that is local to a process? Local to a machine? Something else entirely? Distributed state, does that mean any state not encompassed by the prior definition (state on another process, another machine, etc, than the one we're currently talking about)? State that is implicit in the syste…

I said nothing about STM. I said something about actors vs. "normal programs" ("normal" = "typical").

> are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes?

I'm saying that "consensus" and "a stable view" are things that you needn't concern yourself with if you're not already thinking in terms of the actor model. And you shouldn't have to!

Re: Scala Actors: Unifying thread-based and event-based programming

#18

Post by lostcolony »

lomnakkus wrote: post #17
lostcolony wrote: post #16

Earlier quoted context omitted.

I don't know what you mean to distinguish by using the terms 'local state' vs 'distributed state'. Local state...does that mean state that is local to a process? Local to a machine? Something else entirely? Distributed state, does that mean any state not encompassed by the prior definition (state on another process, another machine, etc, than the one we're currently talking about)? State that is implicit in the syste…

I said nothing about STM. I said something about actors vs. "normal programs" ("normal" = "typical"). > are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'm saying that "consensus" and "a stable view" are things that you needn't concern yourself with if you're not already thinking in terms of the actor model. And you shouldn't have t…

Your response to DanWaterworth made me assume you were speaking from a perspective that valued STM, but fair enough. I agree; 'typical' programs do not lend themselves to actors; you have to change how you write programs (the same would be said for Haskell, of course).

"consensus" and "a stable view" are things you -definitely- need to concern yourself about if you need such things and are working in a distributed environment, actor model or not.

Re: Scala Actors: Unifying thread-based and event-based programming

#19

Post by lomnakkus »

lostcolony wrote: post #18
lomnakkus wrote: post #17

Earlier quoted context omitted.

I said nothing about STM. I said something about actors vs. "normal programs" ("normal" = "typical"). > are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'm saying that "consensus" and "a stable view" are things that you needn't concern yourself with if you're not already thinking in terms of the actor model. And you shouldn't have t…

Your response to DanWaterworth made me assume you were speaking from a perspective that valued STM, but fair enough. I agree; 'typical' programs do not lend themselves to actors; you have to change how you write programs (the same would be said for Haskell, of course). "consensus" and "a stable view" are things you -definitely- need to concern yourself about if you need such things and are working in a distributed en…

I am a fan of STM. I think we may just have been talking at cross purposes -- it's about what the definition of "process" is :).
Post reply on HN