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!

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.

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!

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.

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 :).