Erlang hints for an OO junkie

Johan Warlander <>
Tue Aug 10 11:20:36 CEST 2004

On Tue, 10 Aug 2004 01:12:43 -0700 (PDT), Thomas Lindgren wrote
> 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

Well, that was a bit better than I would've imagined :) If those numbers are
obsolete, I would guess performance has changed for the better rather than worse.

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

Right, though I suspect messages will not be sent at all as frequently as I'd
be calling methods in an OO approach - rather I imagine that one message would
be preceded by some work on the sending side, and generate some work on the
receiving side, instead of sending a big burst of messages back and forth..

I've been browsing Ulf Wikström's "Design Patterns for Simulations in
Erlang/OTP" and that currently leads me to believe that most messages will be
actual events.. though exactly how I don't know yet, I'll need to start
exploring the problem more thoroughly first I think :)

> If you want something OO-like for code organization,
> have a look at Erlang's "behaviours". They work in the
> same spirit as Java's "interfaces". I would also
> suggest taking a look at "abstract data types", if you
> haven't already.

I've been glancing at behaviours, so we'll see what happens.. I'm trying to
avoid OO-like just for the sake of being like OO, though. If I end up leaning
towards OO-like organisation for aspects of the program, I hope it'll be
because I've become well aquainted with most of the common solutions available
in Erlang, and decided that the OO-like solution is the most appropriate for
the task.


More information about the erlang-questions mailing list