Interview with Ryan Dahl, Creator of Node.js • Hacker News Board

Re: Interview with Ryan Dahl, Creator of Node.js

#231

Post by debaserab2 » Sun, Sep 03, 2017, 3:57 AM UTC

z3t4 wrote: post #230

debaserab2 wrote: post #229

Earlier quoted context omitted.

The server spawns the threads and isolates the entirety of a single request to a single thread. It's not true language multithreading.

JavaScript is single threaded, but all IO operations like network and disk uses threads in Node.JS, So there are still racing conditions, like when accessing the file system. But all other operations are single threaded, like storing data in memory. In for example PHP, where the server spawns the threads everything becomes multi threaded. In node.js instead of using locks etc, you use callbacks, so when something is…

> In for example PHP, where the server spawns the threads everything becomes multi threaded.

No it doesn't. The only way to do truly multithreaded code in PHP is using pthreads.

Re: Interview with Ryan Dahl, Creator of Node.js

#232

Post by Johnny_Brahms » Mon, Sep 04, 2017, 6:02 AM UTC

sreque wrote: post #126

ralusek wrote: post #117

Earlier quoted context omitted.

First of all, I have absolutely implemented promises from scratch, and it IS trivial. However, "callback hell" is a reference to writing code with deeply nested callbacks, particularly with manual error handling at each level, both of which promises completely negate. If you want to change the topic from "callback hell" to debugging across stacks, then we can do that. There was some work with "domains," since moved t…

It's still "callback hell" because you're still fundamentally writing code where you invoke an API and pass in a callback to handle the results. The fact that the callback you pass in happens to be a promise that allows you to stage other callbacks and/or promises doesn't really change things enough for the label "callback hell" to be inaccurate in my opinion. A different programming paradigm, for instance, would be…

> A different programming paradigm, for instance, would be the use of delimited continuations such that the API you invoke suspends the current call stack, executes the I/O operation, then resume the call stack with the result of the I/O operation.

guile has recently gotten guile-fibers which works like this. It is really an amazing way to do concurrency.

Re: Interview with Ryan Dahl, Creator of Node.js

#233

Post by ungamed » Tue, Sep 05, 2017, 7:44 AM UTC

ricardobeat wrote: post #214

gshulegaard wrote: post #95

Earlier quoted context omitted.

> Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. What? I am sorry but this is not true. Coroutines have been a concept for...well a long time: https://en.wikipedia.org/wiki/Coroutine…

Remember the "C10K challenge"? Show me what else could achieve those ten thousand concurrent connections back then (hint: no python).

Erlang -easily- acheived the C10k challenge back then.

Re: Interview with Ryan Dahl, Creator of Node.js

#234

Post by jdc0589 » Wed, Sep 13, 2017, 3:16 PM UTC

pawelk wrote: post #109

jdc0589 wrote: post #104

Earlier quoted context omitted.

> Since server-side JS didn't exist yet, I'm being petty, but serverside JS did exist before node (e.g. Narwhal, which I believe is where jsgi and a lot of the commonjs stuff originated)

There was also Rhino in the Java land (I remember working with Helma before Node came out), JScript on IIS, some projects embedding SpiderMonkey. I think node.js finally made server-side JS take off because 1) it was based on V8 which was the new, performance-oriented JS engine powering Chrome, and 2) it was self-contained (i.e. didn't rely on Java on one hand, wasn't just a scripting layer of something larger on the…

> some projects embedding SpiderMonkey

yea, I remember the woes of building CouchDB from source....about half the issues generally seemed to be SpiderMonkey related.

Re: Interview with Ryan Dahl, Creator of Node.js

#235

Post by pawelk » Wed, Sep 27, 2017, 12:13 PM UTC

jdc0589 wrote: post #234

pawelk wrote: post #109

Earlier quoted context omitted.

There was also Rhino in the Java land (I remember working with Helma before Node came out), JScript on IIS, some projects embedding SpiderMonkey. I think node.js finally made server-side JS take off because 1) it was based on V8 which was the new, performance-oriented JS engine powering Chrome, and 2) it was self-contained (i.e. didn't rely on Java on one hand, wasn't just a scripting layer of something larger on the…

> some projects embedding SpiderMonkey yea, I remember the woes of building CouchDB from source....about half the issues generally seemed to be SpiderMonkey related.

On the other hand you could use E4X in CouchDB views, which was almost like JSX, but native.