
Node.js Emerging as the Universal Development Framework - myth_drannon
https://hackernoon.com/node-js-emerging-as-the-universal-development-framework-for-a-diversity-of-applications-c2e788290f5f
======
cutler
Universal? Node.js is little more than an orchestration layer and a poor one
at that considering it crashes when an error isn't handled. It's concurrency
model - async i/o - is inferior to Elixir's actor model and Golang's
goroutines and if you want computation Node.js will have to hand-off to
something else. The only thing Node.js has going for it, once you subtract the
hype, is that you can reuse your front-end Javascript devs. What a claim to
fame.

~~~
johnhenry
Just curious -- what should a program do when an error isn't handled?

~~~
cutler
I'm talking about the whole server. Erlang has a "let it crash" approach where
every process is isolated so the server stays up. Most scripting languages
will produce an error in the logs without the need to reboot the server.

~~~
johnhenry
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
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
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
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.

