Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

171–180 of 235 posts

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

#171
post #111

Earlier quoted context omitted.

I'm well aware of promises, thank you. I'm also well aware that there's very little difference in reality between a promise-based style of coding and a callback one. You still lose stack continuity, it's still much harder to chain operations that hop stacks, it's still a nightmare to debug compared to stack-based programming, etc. If you've ever actually implemented a promise it's even easier to see how little promis…

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…

Callback hell may as well be synonymous with stack incoherence. The hell arises from not knowing from whence you came.

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

#172

Earlier quoted context omitted.

You're getting a lot of pedantic replies, but your post is spot on. At the time it arrived, asynchronous operations were close to impossible in PHP, very difficult and awkward in .NET, and very uncommon in Java. In Node it not only was possible, it was impossible (without going to great efforts) to do otherwise. People have a short memory, but at the time getting single to double digits of requests per second on a be…

> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…

Along those lines: Has anyone seen benchmarks that show significant benefits for non-blocking IO?

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

#173

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

Your claim is that Node was popular because people were excited about writing servers using 100% non-blocking I/O? I guess I agree that's a part of it but we should note that in 99.5% of those cases the servers would've performed better written in Java using blocking threads.

I think the other parts of it are: 1) many people wanted to write server-side Javascript, 2) people did not want to use Java, and the concurrency stories for PHP, Ruby, and Python were (and still are) really crummy.

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

#174
post #102

Earlier quoted context omitted.

If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.

Because not every news website and blog needs an app. I think everybody is tired of seeing the "Install our app" banners for every website you visit.

News websites and blogs don't need to work offline. Even if they did, "save page as" or an RSS reader was the way to go.

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

#175
post #79

Earlier quoted context omitted.

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

Promises made some very valuable improvements to code patterns relative to callback-based implementations, but as a broader "nodejs vs synchronous style code" its still much harder. You sound pretty versed, but other folks might struggle. Here is an example explanation:

https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...

If we're trying to show the simplicity of modern nodejs code with non-blocking I/O, I would suggest we lead with examples like:

const foo = await queryFooObject(id); await writeToFile(foo);

True, there's still plenty of value in promises, especially for things like:

await Promise.all(severalParallelQueries);

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

#176

Earlier quoted context omitted.

You're getting a lot of pedantic replies, but your post is spot on. At the time it arrived, asynchronous operations were close to impossible in PHP, very difficult and awkward in .NET, and very uncommon in Java. In Node it not only was possible, it was impossible (without going to great efforts) to do otherwise. People have a short memory, but at the time getting single to double digits of requests per second on a be…

> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…

I said entirely typical, not that it was a dick-sized "challenge".

A completely standard developer on .NET or PHP in 2008 was building pages that rendered at less than 10 requests per second. This is experience, not a guess, given that my role was improving the performance of those disasters. A completely average developer on node was building pages that was 10x to 100x better performance.

Secondly, simply spawning threads is laughably non scalable.

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

#177

Earlier quoted context omitted.

> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…

I said entirely typical , not that it was a dick-sized "challenge". A completely standard developer on .NET or PHP in 2008 was building pages that rendered at less than 10 requests per second. This is experience, not a guess, given that my role was improving the performance of those disasters. A completely average developer on node was building pages that was 10x to 100x better performance. Secondly, simply spawning…

Not the OP, but I knew what you meant I soon as I read it. But, did the typical .NET app really not make use of the Asynchronous Programming Model that was part of the standard library?

I ask because in 2008 I was only about 3 years into professional web development, and even I knew about stuff like the C10K problem[1] and that I/O Completion ports were apparently one of the few things that Unix people admired about Windows.

[https://en.m.wikipedia.org/wiki/C10k_problem]

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

#178
post #120

this new paradigm of model view controller New... in the 1970s https://en.wikipedia.org/wiki/Model–view–controller#History It boggles the mind how little "web devs" know about the history of the field. No wonder they keep reinventing the wheel.

Maybe he's talking about when it got popular, not when it was literally invented...but I guess you can just be pedantic and miss the point.

The GP's interpretation was arguably uncharitable, but your reply was uncivil. When you have a good point, please don't use it to make the thread worse.

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

#179
post #53

Earlier quoted context omitted.

I agree that we regularly fail to learn from history. However, it's worth recognizing that trying to learn from history can be incredibly challenging. There's a mountains of research to filter through. Sometimes you discover a relevant document, only to find out it's not readily available or that you have to pay an exorbitant amount of money for access. You might pay a lot of money for something that doesn't even end…

A good example - I have no idea why unix filesystems are like that, and after some idle googling I still don't know. Can't even figure out where to start to find the history of those decisions. Certainly am finding what kind of stuff goes where.

Some old Unix devs/users ran out of disk space, so they mounted more disk to those points. This caused boot problems since some tools (like mount) needed to be available. All of that together, along with people blindly following convention, and you have the mess of the unix filesystem. Yep... [1]

[1] http://lists.busybox.net/pipermail/busybox/2010-December/074...

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

#180
"And then, you know, maybe little servers to... maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you're building a massively distributed DNS server, I would not choose Node." -Ryan
Post reply on HN