Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

Post reply on HN
Print view View original

111–120 of 235 posts

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

#111

Post by sreque »

ralusek wrote: post #100
sreque wrote: 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…

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 promises actually get you. Given a callback-based API, it's absolutely trivial to wrap it in a Promise-based API. Fundamentally this is because promises give you very little in the end on top of callbacks beyond some syntactic sugar.

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

#112

Post by sreque »

tmp124567 wrote: post #87
sreque wrote: 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…

You don't know what you are talking about. Code some simple server on c using epoll I think you could learn a lot from that. And JS has async await now, so no callbacks.

I have written servers in C with epoll that were used in production, thank you. And yes, I'm aware of async/await and its limitations. State-machine-style transformations from blocking-looking code to non-blocking code are definitely helpful, but in the end still fall short in terms of usability to a full blocking style of programming.

To even begin to approach the ease-of-use of blocking-style programming you need something akin to delimited continuations in your programming language.

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

#113

Post by sreque »

WA wrote: post #88
sreque wrote: 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…

So if I don't like Java and C, what's your suggestion I should use instead to get the best of both worlds and not the worst?

C# is fairly efficient while still having managed memory. And, of course, golang was designed to hit the sweet spot of automatic memory management, decent performance, and non-blocking I/O.

Beyond that, there's things like Erlang and Elixer, which I am less familiar with. My understanding is that the Erlang VM is significantly slower than JVM or CLR implementations but generally faster than scripting language runtimes.

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

#114

Post by AgentME »

nulagrithom wrote: post #68
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,…

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…

A little tip from someone coming back into Java after using modern javascript / node.js lately: Java 8's CompletableFutures are basically Java's Promises, and they have good support for doing steps in specific thread pools. (Regular Futures are way too limited: if you want to do an action as soon as a Future resolves, then you have to dedicate a thread just to blocking on that Future, which is not exactly what you want if you have a lot of simultaneous asynchronous operations of multiple steps going on.)

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

#115

Post by _pmf_ »

valarauca1 wrote: post #59
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,…

Each language had some niche library that did non-blocking I/O [...] Netty for Java) Non-blocking IO has been in java standard library since 1.4 More then Netty supported it. Netty, Jetty, Dropwizard, Grizzly, VERTX. Apache Tomcat supported non-blocking IO 5 years ago.

To recap for the non-Java reader: the problem was that the Servlet specification did not initially support suspending and resuming without suspending and resuming the thread handling the request. The Servlet 3.0 specification supports it, but before you could not use multiplexed IO within containers that required the servlet interface, even though IO multiplexing worked perfectly fine (and, as you said, some containers allowed it via a custom interface, since it is pretty much trivial to add).

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

#116

Post by davedx »

nulagrithom wrote: post #68
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,…

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…

Elixir does it very well, I think.

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

#117

Post by ralusek »

sreque wrote: post #111
ralusek wrote: post #100

Earlier quoted context omitted.

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…

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 to AsyncListener/Continuation Local Storage to keep context across stack calls, but I don't disagree that improvements in this department are the place that NodeJS paradigm would currently benefit from most.

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

#118

Post by ehsanu1 »

sreque wrote: post #111
ralusek wrote: post #100

Earlier quoted context omitted.

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…

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…

How about that await though.

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

#119

Post by sah2ed »

mikewhy wrote: post #99
sah2ed wrote: post #83

Earlier quoted context omitted.

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

It's an exaggeration, yes, but it does correctly summarize how I felt when I had to work with node.js code bases before stuff like promises became mainstream.
Post reply on HN