4 ms·

> I realized just how poor the async/await/promise design Node.js was (error-prone by design) It's so weird to me when people make statements like this and it

by dimgl 3y ago

> I realized just how poor the async/await/promise design Node.js was (error-prone by design) It's so weird to me when people make statements like this and it makes me wonder how many times I've been swayed by someone's opinion online who doesn't understand the fundamentals of what they're talking about (or they do, and they just have horrible taste). Node.js's asynchronicity is quite literally one of the, if not the, best part of Node.js.

pessimizer 3y ago
> who doesn't understand the fundamentals of what they're talking about (or they do, and they just have horrible taste). You have no idea what the person you're talking about knows or doesn't know, so your comment is ironic. > Node.js's asynchronicity is quite literally one of the, if not the, best part of Node.js. But enough about your emotional life. Do you have any interesting reason for saying this?
- dimgl 3y ago
  I'm surprised you think it's emotional. Seems pretty rational to me. I thought Node.js's selling point is the event loop and its non-blocking nature, and how convenient it is to be able to write both your backend and frontend code in a shared runtime. The arguments against that paradigm, mostly around callback hell and promise chaining, have gone away with async/await. So I stand by my assessment that these parts are probably the best parts of Node.js. There are many other parts of Node.js which need work, but it's weird when the thing to call out is its asynchronicity when that part of the language is usually the thing people like.
widdershins 3y ago
Asynchronicity is indeed part of what makes Node.js useful, but that doesn't mean it's perfect. It's very easy to write non-deterministic bugs with async/await. Bugs that might result in flaky tests and incorrect code getting checked in.
bmitc 3y ago
The best part of a terrible language and ecosystem is a pretty low bar.
hosh 3y ago
“Node.js’s asynchronicity is quite literally one of the, if not the best part of Node.js” That’s fine if that is your opinion. Here is my perspective on it: - Node.js async model is not unique nor innovative. There has been several other platforms (such as Tcl/TK or 90s Windows programming). It runs into the same problem with any cooperative concurrency control, where a block of execution can freeze out everything else. In contrast, the Erlang/Elixir has a preemptive scheduler - Nodejs’s async/await has an implicit queue of execution blocks. Erlang/Elixir, on the other hand, queues _messages_ recieved by a process. This allows not only transmission of data, but also control signals (such as suspend, stop, restart), which you cannot do with Nodejs promises alone. You have to use event emitters, whereas every Erlang/Elixir lightweight process can receive event messages. - Nodejs promises can get lost. If it is not held and tracked somewhere, you can’t get to it. Erlang and Elixir has a first-class, PID literal. You can pull up any running process because the scheduler tracks them, which makes live debugging or mitigations possible in prod - Because Nodejs queues execution instead of messages, it has to use callbacks. The problem with callbacks are not necessarily callback hell so much as tracking rejections and errors. Every single async call requires it, whereas in Erlang and Elixir, a running process is a natural error isolation boundary. - Nodejs only occupies a single core of a processor, unless you use workers or fork. The BEAM runtime (these days) will use up as many of the cores as available unless you tell it not to. I can run a single BEAM os process, but have to jump extra hoops to take advantage of that for Nodejs. Those are the main reasons why, from my perspective, Nodejs is error prone by design.
- dimgl 3y ago
  These are some great points. I'm glad I left that message :) It's always interesting to hear the other side

by dimgl 3y ago

pessimizer 3y ago

> who doesn't understand the fundamentals of what they're talking about (or they do, and they just have horrible taste). You have no idea what the person you're talking about knows or doesn't know, so your comment is ironic. > Node.js's asynchronicity is quite literally one of the, if not the, best part of Node.js. But enough about your emotional life. Do you have any interesting reason for saying this?

dimgl 3y ago
I'm surprised you think it's emotional. Seems pretty rational to me. I thought Node.js's selling point is the event loop and its non-blocking nature, and how convenient it is to be able to write both your backend and frontend code in a shared runtime. The arguments against that paradigm, mostly around callback hell and promise chaining, have gone away with async/await. So I stand by my assessment that these parts are probably the best parts of Node.js. There are many other parts of Node.js which need work, but it's weird when the thing to call out is its asynchronicity when that part of the language is usually the thing people like.

widdershins 3y ago

Asynchronicity is indeed part of what makes Node.js useful, but that doesn't mean it's perfect. It's very easy to write non-deterministic bugs with async/await. Bugs that might result in flaky tests and incorrect code getting checked in.

bmitc 3y ago

The best part of a terrible language and ecosystem is a pretty low bar.

hosh 3y ago

“Node.js’s asynchronicity is quite literally one of the, if not the best part of Node.js” That’s fine if that is your opinion. Here is my perspective on it: - Node.js async model is not unique nor innovative. There has been several other platforms (such as Tcl/TK or 90s Windows programming). It runs into the same problem with any cooperative concurrency control, where a block of execution can freeze out everything else. In contrast, the Erlang/Elixir has a preemptive scheduler - Nodejs’s async/await has an implicit queue of execution blocks. Erlang/Elixir, on the other hand, queues _messages_ recieved by a process. This allows not only transmission of data, but also control signals (such as suspend, stop, restart), which you cannot do with Nodejs promises alone. You have to use event emitters, whereas every Erlang/Elixir lightweight process can receive event messages. - Nodejs promises can get lost. If it is not held and tracked somewhere, you can’t get to it. Erlang and Elixir has a first-class, PID literal. You can pull up any running process because the scheduler tracks them, which makes live debugging or mitigations possible in prod - Because Nodejs queues execution instead of messages, it has to use callbacks. The problem with callbacks are not necessarily callback hell so much as tracking rejections and errors. Every single async call requires it, whereas in Erlang and Elixir, a running process is a natural error isolation boundary. - Nodejs only occupies a single core of a processor, unless you use workers or fork. The BEAM runtime (these days) will use up as many of the cores as available unless you tell it not to. I can run a single BEAM os process, but have to jump extra hoops to take advantage of that for Nodejs. Those are the main reasons why, from my perspective, Nodejs is error prone by design.

dimgl 3y ago
These are some great points. I'm glad I left that message :) It's always interesting to hear the other side