Erlang hints for an OO junkie

[Vlad Balin]

>> where would I start running into performance
>> problems as far as
>> concurrent processes go?

> My rules of thumb (possibly obsolete) are these:
> - one Erlang VM (node) can have about 200,000
> processes
> - one freshly started process uses about 1 KB
Exactly. This is one of the reasons why processes cannot be used as objects.

> Using objects-as-processes and ubiquitous message
> passing, a la method invocation in OO, _might_ become
> a performance problem. Erlang is asynchronous, so if A
> sends a message to B, some effort is needed to context
> switch from A to B, and some time may pass before B is
> scheduled to handle the message. (Clever
> implementations may get rid of some overhead, but it's
> probably good to be aware of the issue.)

There's an another problem. Erlang is functional language, where destructive
updates and other side effects are not desirable things.

If you will use processes as a unit of incapsulation (think of it as object)
you
will introduce destructive updates, and loose the benefits of Erlang as
functional language.
I'm going to demonstrate it.

Process is "object", with a message loop dispatching "messages", like in a
Smalltalk.
Something like this:

loop( State ) ->
	receive	{ Caller, MethodName, Params } ->
		{ Result, NewState } = apply( className, MethodName, [ State | Params ] ),
		Caller ! Result,
		object( State )
	end.

And you may want to call "methods" like this:

invoke( Object, Method, Params ) ->
	Object ! { self(), Method, Params },
	receive Result -> Result.

And you're using the process ID as a reference to the "object". Cool. Your
objects
has state, you may pass objects as a parameters and do other familiar
things. But
look here, what would be the often seen in your code:

method( State, Object1 ) ->
	{ AggregatedObject, _, _ } = State,
	{ invoke( AggregatedObject, doDestructiveUpdate, [ Object1 ] ), State }.

Miracle! State of the caller has _not_ been changed when we have updated its
part.
An innocent message sending side effect has been grown in evil destructive
update.
If you going to use it your design as a leading principle, the better idea
would be
to use Smalltalk instead, not to emulate it in Erlang.

So what is wrong here? Processes should _not _ be widely used as unit of
incapsulation, or you will not take benefit of referential transparency. And
if you do so,
you would better use non-functional language.