I have a whole other blog post planned at some point to go through Erlang's concurrency mechanisms and explain how it all works and highlight the parts that are counterintuitive at first.
Basically, typical "enterprise" systems attempt to get reliability and robustness with a heavyweight approach: buy big, high end, expensive servers, run Oracle on them, and use layer upon layer of abstraction, relying on checked exceptions and static typing to try to catch all your errors at compile time.
Meanwhile, Erlang makes it easy to get nine nines of uptime on clusters of tiny memory constrained embedded systems running a weakly typed, dynamic language and focusing on extremely simple architectures based on functional programming and where processes are expected to die loudly and quickly as soon as they encounter anything unexpected. Somehow they're able to get all the advantages of rapid application development with very short line counts, readable, modular code, fast edit/compile/run cycles (Erlang even lets you replace a module in place in a running server process without restarting or even having it miss a single request), complete lack of xml situps, etc. yet it still achieves uptime to make j2ee developers jealous with performance comparable to C (spawning an Erlang process takes fewer cycles than calling a function in C on many processors).
But like I said, this is all for another post later.
anders pearson - 2006-08-14 17:14:28
I have a whole other blog post planned at some point to go through Erlang's concurrency mechanisms and explain how it all works and highlight the parts that are counterintuitive at first. Basically, typical "enterprise" systems attempt to get reliability and robustness with a heavyweight approach: buy big, high end, expensive servers, run Oracle on them, and use layer upon layer of abstraction, relying on checked exceptions and static typing to try to catch all your errors at compile time. Meanwhile, Erlang makes it easy to get nine nines of uptime on clusters of tiny memory constrained embedded systems running a weakly typed, dynamic language and focusing on extremely simple architectures based on functional programming and where processes are expected to die loudly and quickly as soon as they encounter anything unexpected. Somehow they're able to get all the advantages of rapid application development with very short line counts, readable, modular code, fast edit/compile/run cycles (Erlang even lets you replace a module in place in a running server process without restarting or even having it miss a single request), complete lack of xml situps, etc. yet it still achieves uptime to make j2ee developers jealous with performance comparable to C (spawning an Erlang process takes fewer cycles than calling a function in C on many processors). But like I said, this is all for another post later.