[erlang-questions] The future of Erlang and BEAM

[Miles Fidelman]

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