[erlang-questions] The future of Erlang and BEAM

[Radek]

Dear Group,

first of all, I am pretty amazed that my question started such a nice 
discussion with interesting posts.
What amazes me even more, that (with full&great respect to the others) 
even such known people like Joe Armstrong or Ulf Wiger found some time 
to answer me directly. I think it's truly amazing :)

Thank you very much, all of you, for such interesting answers. Now I 
think I understand what is the real difference between Erlang & rest of 
the world. I really haven't thought about safety and reliability in the 
first place. Now it seems to be logical for me that "raw performance" 
isn't an only factor which I should consider.

Thank all of you very much, once more. Now I think I'm Erlang fab-boy 
even more :)

Greetings,
Radek


W dniu 2012-02-11 19:48, Miles Fidelman pisze:
> 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
>
>
>
>
>