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