Joe,
I'll add one more thing - correct me if I'm wrong here (you are, after
all the expert :-)....
Joe Armstrong wrote:
> To start with you are comparing chalk with cheese - Erlang was
> NOT designed to be a fast messaging passing language. It was designed
> for building fault-tolerant applications - it wasn't designed
> for speed it was designed for safety.
>>Erlang also is really nice for building systems where you want to THINK
and organize your code in terms of concurrent processes. Simulation is
the application that comes to mind (based on my own experience).
If you want to simulate 10,000 tanks, on a simulated battlefield - my
first instinct is "each tank is a process." Turns out, that most (all?)
conventional simulators model each tank as an object, with a small
number of threads touching each object 20-40 times per second (a state
update thread, a display thread, etc.) Leads to really horrible
spaghetti code and systems that are really hard to change.
I found Erlang when I joined a simulation software house, after a
background in networking (where we spawn processes all the time).
Programmers kept telling me that "we can't spawn 10,000 processes, the
overhead will kill us" - which is true with C++ (what we were using) or
Java. I did some digging and found Erlang as a counter-example.
I guess what I draw from this is that, while Erlang might not be
blindingly fast for some applications, if I want to write code that
spawns 1000s of processes, it's a lot faster than anything else around.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra