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

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

#91

Post by gkya » Thu, Aug 31, 2017, 7:16 PM UTC

stephenr wrote: post #32

amasad wrote: post #14

Earlier quoted context omitted.

The fact that Node survives as a platform for Fullstack JavaScript shows how serendipity works in invention: he set out to build a high performance network server and ended up building one of the largest platforms for building web applications. The reasons it ended being very big are clear in hindsight but are hard to predict: - Sharing code between server and client - Server side rendering - Lower barrier to entry t…

I wouldn't call npm "well designed". It's progres bar was the bottleneck causing slow downs. The size of node_modules directories is basically a meme now.

> The size of node_modules directories is basically a meme now.

Not a node user since many years, so I can only guess, but isn't the cause of this is bad community practices (micro-packaging, many different things that do the same thing, etc) rather than the package manager itself? You can get hundreds of deps in any language if the practices are similar.

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

#92

Post by a13n » Thu, Aug 31, 2017, 7:16 PM UTC

cdelsolar wrote: post #73

nulagrithom wrote: post #68

Earlier quoted context omitted.

On that note, coming back from node.js has been a really frustrating experience for me. I want to scream every time somebody suggests threading as a solution to non-blocking database calls and HTTP requests. It's made me painfully aware of how often parallelism is suggested in place concurrency. C# in particular does a great job at conflating concurrency and parallelism. Both fall under the same Task namespace and it…

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

async await though

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

#93

Post by tmp124567 » Thu, Aug 31, 2017, 7:16 PM UTC

bit_logic wrote: post #49

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. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

This. I'am allways surprised by the amount of developers that don't understand the difference between threads, epoll-select and forking and io bound vs cpu bound.

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

#94

Post by watwut » Thu, Aug 31, 2017, 7:18 PM UTC

dsacco wrote: post #19

I find it interesting that he ended up at Google Brain working on deep learning research after writing Node. There seems to be a trend in the industry of taking people who are exceptional in one area and putting them on AI problems (e.g. Chris Lattner). I wonder how effective that cross pollination is.

These AI projects require a lot of math. Someone who studied math and is also proven to be able to produce working software seems to be a great fit.

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

#95

Post by gshulegaard » Thu, Aug 31, 2017, 7:18 PM UTC

bit_logic wrote: post #49

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. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

> 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

Green threads also have been around for a while.

> but these all had a critical flaw, which is the rest of the ecosystem didn't support it. Basically every library, almost all existing code used the threading model. And when you mix threaded libraries with a non-blocking I/O server, it completely falls apart because the threaded code blocks.

I am not sure how you can say this while using Python as an example. Python has the GIL which, typically viewed as a limitation, actually prevents the situation your assertion suggests. In fact, one of the largest barriers to removing the GIL is the wealth of libraries and C-extensions to Python that implicitly rely on the thread safety guarantees/limitations of the GIL (as covered by Larry Hastings as part of his first Gilectomy talk).

To be clear, there are reasons Node became popular, but let's not pretend that it brought some sort of concurrency revolution to the "server-side landscape" in 2009.

Edit: Heck, NGINX was an asynchronous, event driven web engine released in 2004 and written in C:

https://en.wikipedia.org/wiki/Nginx

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

#96

Post by paulddraper » Thu, Aug 31, 2017, 7:19 PM UTC

a13n wrote: post #92

cdelsolar wrote: post #73

Earlier quoted context omitted.

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

async await though

And no shared-memory CPU parallelism.

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

#97

Post by camus2 » Thu, Aug 31, 2017, 7:20 PM UTC

jerf wrote: post #69

camus2 wrote: post #33

Earlier quoted context omitted.

> Using ideas from history isn't a problem. And Go is unique in that it combined all these learned lessons into something new. what learned lessons, like pragmas and struct tags?

A lot of is more in what was taken away rather than what was added. As someone who is occasionally accused of being too pro-Go on HN... I actually have no problems thinking of Go as a really nice and refined 1990s language. Another type of "Java done right". (I say "another" because I think C# has a really good claim to that as well, albeit in a very different direction.) There's a place for that in the world. As muc…

> A lot of is more in what was taken away rather than what was added.

Given the fact that C is basically the blueprint for Go, I'm not sure what things were taken away from C, syntactically speaking. It's more like Go added garbage collection to C, and a few other bells and whistles and told people : "this is 21th century programming", without actually thinking about what C got wrong at first place.

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

#98

Post by AgentME » Thu, Aug 31, 2017, 7:20 PM UTC

cmiles74 wrote: post #61

bit_logic wrote: post #49

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. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

I think the only new thing that node.js brought to the table was a nice way to run Javascript on the server. Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). In addition, Java has had non-blocking I/O (in the form of the nio) packages for quite some time. In my opinion, Node.js became popular because people wanted to run Javasc…

>Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty).

The new thing that it brought was an entire environment that used non-blocking I/O exclusively without any pre-existing thread-based code and libraries. With node.js, you don't have to wonder if a library you want to adopt supports non-blocking I/O.

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

#99

Post by mikewhy » Thu, Aug 31, 2017, 7:21 PM UTC

sah2ed wrote: post #83

k__ wrote: post #58

Earlier quoted context omitted.

Somehow I never experienced callback hell. It always felt like every other code-nesting problem to me. I mean, nobody talks about conditional hell, everyone acknowledges that you should flatten out your conditionals.

Callback hell was real, especially if you worked on projects that decided to join the node.js bandwagon in its early days. Then promises happened. https://twitter.com/winterbe_/status/541868081308790784

Why post a contrived meme as an example? Especially one with a sane solution[1] just below.

[1]: https://pbs.twimg.com/media/B4W2AmaCAAA-heo.png

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

#100

Post by ralusek » Thu, Aug 31, 2017, 7:23 PM UTC

sreque wrote: post #79

bit_logic wrote: post #49

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. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

Node.js brings callback hell to the serverside world of threads and we're supposed to be grateful? It's like you don't know the history of computing. Callback-based code was the original programming model in UNIX dating back decades! Threaded code came about because it's far easier to write it than callback-based code. The ONLY reason to do callback-based code is for performance reasons: for network-IO-heavy apps the…

I should definitely make a macro at this point:

Callback paradigm has not been used in node development for 3-4 years at this point.

    return someHttpCall()
    .then(response => someOtherHttpCall(response))
    // Do 2 async operations in Parallel:
    .then(response => Promise.join(
      someCacheThing(response),
      someDBThing(response)
    ))
    .spread((cacheResponse, dbResponse) => sendBackToClient());

This isn't callback hell. Without creating or managing threads, I have established serial as well as an example of branched concurrent logic that is entirely nonblocking. Every promise is handled as a try catch, so error handling can be done at the end of the chain with a single `.catch`.

Clustered express application puts the performance well within what you would expect from Go/Phoenix, all of which are operating at an order of magnitude above Python/Ruby.