3 ms·

Can you describe your experience with node, specifically, how it has different from what you experience with Erlang? I feel like that would help me to understan

Can you describe your experience with node, specifically, how it has different from what you experience with Erlang? I feel like that would help me to understand your comment better.

cutler 9y ago
Node.js is an event loop which is accessed via Javascript callbacks which are invariably nested. Each nested callback must have an error-handler otherwise the error "bubbles" to the top of the call stack and crashes the server because a Node.js server runs in a single process. Erlang and Elixir, on the other hand, handle requests with real concurrency, spawning many small "green threads" within the Erlang VM, not OS proceses. These lightweight processes can crash without affecting the other threads running in the same VM and co-ordination of these threads is handled by a genserver. Golang has a similar concurrency model but without the benefit of Erlang's genserver so you have a greater chance of race conditions. Why the world opted for the Node.js model of "concurrency" I will never understand. Then again, Java and Javascript are still the most popular languages in the industry so what does language design have to do with anything?
- johnhenry 9y ago
  Your description of nested call backs sounds terrifying. I don't think the issue here is with the language, but rather your approach to it. Nested callbacks can be a pain, but it seems like the solution here may be to ensure that you properly handle your errors rather than expecting everything to continue to work when everything goes down -- seems like a safer approach to me. Even so, many newer features in javascript involving Promises and async/await can help you avoid callbacks, so the nested call backs isn't really an issue. I'm curious -- what's your issue with Java? It's very different from Javascript, and the concurrency models are vastly different?
  - cutler 9y ago
    My issue with Java is its lack of expressiveness, its culture of verbosity and that everything must be a class. Kotlin is a big improvement but the typical Java programmer is very conservative so unlikely to adopt it.
  - cutler 9y ago
    Promises and async/await are really syntactic sugar. The error handling issue still remains. My original point was that Node.js is the least universal platform I can think of. Sure, you can attempt all things with it but it's not optimised for anything other than lightweight orchestration.

Can you describe your experience with node, specifically, how it has different from what you experience with Erlang? I feel like that would help me to understand your comment better.

cutler 9y ago

Node.js is an event loop which is accessed via Javascript callbacks which are invariably nested. Each nested callback must have an error-handler otherwise the error "bubbles" to the top of the call stack and crashes the server because a Node.js server runs in a single process. Erlang and Elixir, on the other hand, handle requests with real concurrency, spawning many small "green threads" within the Erlang VM, not OS proceses. These lightweight processes can crash without affecting the other threads running in the same VM and co-ordination of these threads is handled by a genserver. Golang has a similar concurrency model but without the benefit of Erlang's genserver so you have a greater chance of race conditions. Why the world opted for the Node.js model of "concurrency" I will never understand. Then again, Java and Javascript are still the most popular languages in the industry so what does language design have to do with anything?

johnhenry 9y ago
Your description of nested call backs sounds terrifying. I don't think the issue here is with the language, but rather your approach to it. Nested callbacks can be a pain, but it seems like the solution here may be to ensure that you properly handle your errors rather than expecting everything to continue to work when everything goes down -- seems like a safer approach to me. Even so, many newer features in javascript involving Promises and async/await can help you avoid callbacks, so the nested call backs isn't really an issue. I'm curious -- what's your issue with Java? It's very different from Javascript, and the concurrency models are vastly different?
- cutler 9y ago
  My issue with Java is its lack of expressiveness, its culture of verbosity and that everything must be a class. Kotlin is a big improvement but the typical Java programmer is very conservative so unlikely to adopt it.
- cutler 9y ago
  Promises and async/await are really syntactic sugar. The error handling issue still remains. My original point was that Node.js is the least universal platform I can think of. Sure, you can attempt all things with it but it's not optimised for anything other than lightweight orchestration.