Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

61–70 of 235 posts

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

#61

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 Javascript in a server environment.

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

#62
post #3
post #2

> That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever. Really interesting. I can imagine others would refuse to give up on the thing they'd worked so hard on. But Dahl has the self-awareness to just step back an…

Agree. It takes a lot to walk away from something and say you were wrong. But, sadly, part of the saga of nodejs could have been avoided by people looking at the history of computing. If you look at Go's concurrency model it was entirely mapped out in the 1970s in CSP. There wasn't really any need for go the 'single thread, non-blocking' route that nodejs took and evangelize it as nirvana. There was a ton of distribu…

More than that. Go's model is just threads with a particularly idiosyncratic implementation, in userspace instead of in the kernel. This itself is nothing new, as it was tried by the Linux NGPT project in the early '90s. (NGPT was abandoned for being inferior to plain old 1:1 threads, which suggests that Go's approach is not the end state either.)

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

#64

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,…

IMO, the biggest reason Node.js got popular was because of JavaScript. You just need to learn one language to do full stack development. No need to deal with Python or Java or whatever. Being single-threaded is a side effect of using V8, which is mostly single-threaded. Since you only have one thread, you need IO to be non-blocking.

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

#65
post #29

Earlier quoted context omitted.

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.

That's an awful term because it has nothing to do with the actual meaning of the word "isomorphic".

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

#66
post #64

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,…

IMO, the biggest reason Node.js got popular was because of JavaScript. You just need to learn one language to do full stack development. No need to deal with Python or Java or whatever. Being single-threaded is a side effect of using V8, which is mostly single-threaded. Since you only have one thread, you need IO to be non-blocking.

Yeah, I think this is the primary reason it really had traction. There was definitely some initial hype around async and performance, but there are a lot of ways (especially now) to achieve that without Node. The real win for me is a familiar language with a huge community and package ecosystem on the server that you likely have to use anyways in the browser.

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

#67
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.

Just use pip for a minute, and you'll quickly realize that npm is pretty well designed ;)

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

#68

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,…

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 drives me mad to no end. I've also seen a couple instances of Execute and ExecuteAsync both blocking because the underlying driver didn't support async, with no indication other than my async calls blocking.

It's quite different from the async-by-default sort of thing that's going on in the node.js world.

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

#69
post #33
post #21

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.

> 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 much as I love the cutting edge of programming languages too, I'm not sure that we're anywhere near as far along on knowing how to build really big systems with them as a lot of people think we are. (There's only one way to get there though, and I absolutely encourage people to keep trying.)

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

#70
post #34

Pretty cool how he took a very unusual career/personal route to become such an important figure in the programming world. Good reminder for a parent like me that getting your kids into a "top" school isn't a must to succeed.

I mean, he went to two "Top 50" schools studying math. Do you mean he didn't go to an Ivy League or a school traditionally known as a top CS school?

Yes correct (and not saying that top schools are really top; good article on selection bias a few weeks ago on this).

I was primarily pointing at the fact that he started in Community College, which is sometimes looked down upon.

Post reply on HN