4 ms·

supervisors and process hierarchy is missing from his list of things erlang does really well (he mentions fault tolerance but ties it to distributed computing).

supervisors and process hierarchy is missing from his list of things erlang does really well (he mentions fault tolerance but ties it to distributed computing). for node.js to implement the message passing/process linking that erlang has would be difficult; and it would be easy for node to then lose some of what makes it so interesting.

davidw 16y ago
I was trying to list practical things - what category would you put the process stuff under? In other words: process supervisors are not really an end unto themselves, they're part of what makes Erlang good at X.
- silentbicycle 16y ago
  The process hierarchy is a big part of what makes coding in a "let it crash" style possible, and AFAIK it's fairly unique to Erlang (though some other languages have copied it). Pattern matching is another big part of it, but several other languages did pattern matching first.
  - davidw 16y ago
    Sure, but if you're talking at a high level, what is the "let it crash" stuff good for at a practical level? I think I'd put it under 'fault tolerance', but maybe there's another category I should add? The original poster mentions I left it out, so it'd be fair to add it, but it needs a high-level, practical label to put it under.
    - silentbicycle 16y ago
      Fault tolerance and declarative programming. It's easier to write code that clearly expresses your intent when you don't need to clutter it with error-handling code. Likewise, pattern matching completely eliminates complex layering of nested 'if' statements, and is an alternative solution to the kinds of problems typically solved with polymorphic dispatch in OO languages.
    - gordonguthrie 16y ago
      The first key point about 'let it crash' is that you drive towards zero-defect programming. Every time the system walks away from the happy path you crash write a log. Every day with our production systems we check the live production logs to identify defects that we try and remove. The second key point about 'let it crash' is that with OTP your system is always macro stable. Even if every function is only a stub and every stub contains exit(bleh) and always fails at a micro level, your system is always macro stable - the gift that keeps on giving!
- jhancock 16y ago
  "let is crash" is critical to the erlang approach. erlang's approach to concurrency fails without it. I recommend reading Joe Armstrong's thesis: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf Your comparison of erlang and node.js is a reasonable exercise. However, I think the most valuable thing to get out of the exercise is that node is not really in competition with erlang. I think its more interesting to look at how node can be used to handle non-blocking http requests (and compare that to rails/django) and write your server code in the same language as your client side code.
  - davidw 16y ago
    There are areas where they clearly don't compete at all (phone switches come to mind), but I think that for many web/networking type things, they do compete.

davidw 16y ago

I was trying to list practical things - what category would you put the process stuff under? In other words: process supervisors are not really an end unto themselves, they're part of what makes Erlang good at X.

silentbicycle 16y ago
The process hierarchy is a big part of what makes coding in a "let it crash" style possible, and AFAIK it's fairly unique to Erlang (though some other languages have copied it). Pattern matching is another big part of it, but several other languages did pattern matching first.
- davidw 16y ago
  Sure, but if you're talking at a high level, what is the "let it crash" stuff good for at a practical level? I think I'd put it under 'fault tolerance', but maybe there's another category I should add? The original poster mentions I left it out, so it'd be fair to add it, but it needs a high-level, practical label to put it under.
  - silentbicycle 16y ago
    Fault tolerance and declarative programming. It's easier to write code that clearly expresses your intent when you don't need to clutter it with error-handling code. Likewise, pattern matching completely eliminates complex layering of nested 'if' statements, and is an alternative solution to the kinds of problems typically solved with polymorphic dispatch in OO languages.
  - gordonguthrie 16y ago
    The first key point about 'let it crash' is that you drive towards zero-defect programming. Every time the system walks away from the happy path you crash write a log. Every day with our production systems we check the live production logs to identify defects that we try and remove. The second key point about 'let it crash' is that with OTP your system is always macro stable. Even if every function is only a stub and every stub contains exit(bleh) and always fails at a micro level, your system is always macro stable - the gift that keeps on giving!
jhancock 16y ago
"let is crash" is critical to the erlang approach. erlang's approach to concurrency fails without it. I recommend reading Joe Armstrong's thesis: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf Your comparison of erlang and node.js is a reasonable exercise. However, I think the most valuable thing to get out of the exercise is that node is not really in competition with erlang. I think its more interesting to look at how node can be used to handle non-blocking http requests (and compare that to rails/django) and write your server code in the same language as your client side code.
- davidw 16y ago
  There are areas where they clearly don't compete at all (phone switches come to mind), but I think that for many web/networking type things, they do compete.