Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

131–140 of 235 posts

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

#131
post #111

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…

>>> I'm also well aware that there's very little difference in reality between a promise-based style of coding and a callback one.

Then you're not using promises as they are intended to be used.

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

#132
post #97
post #69

Earlier quoted context omitted.

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.

What mistakes does Go copy from C?

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

#133
post #102
post #27

Earlier quoted context omitted.

Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.

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.

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

#134

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

Yup.

Node.js isn't quite as old as you make it out to be, there were plenty of mature tech stacks out there with PHP/Perl, Ruby, C#, etc. Many of them perfectly fine to work with. Node.js came along with a very different conceptualization of scalability relative to other web-servers, and that was what drew people to it. Today we have things like varnish, nginx, fast-cgi, etc. as well as much faster servers which make it a lot easier to scale out web stuff without having to redesign it from the ground-up, but node.js was for its time a hugely advantageous way to approach scaling. And it still is for many use cases, but today it's matured into something that has a lot more to offer.

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

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

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

#136

Earlier quoted context omitted.

I remember distinctly at the time that the fact that there was excitement around node.js because it was built from the ground up to use evented IO exclusively. All the libraries, the core runtime etc. People in other languages (C) were for sure doing it, but not in the holistic way node was. As opposed to java and python where you needed to avoid using the library calls that were blocking.

Fair enough, I agree that Node.js uses the evented model (AFAIK) almost exclusively. Still, the evented model is not unique to Node.js nor did they invent it. In my opinion, it was the dedication of Javascript developers and their reluctance to use another language that popularized this model: they had no choice.

Yeah. Ryan Dahl was pretty clear at the time that he was inspired by people using C and achieving really high connection counts on single machines. So he for sure was inspired by others, and obviously built off the same foundations in the kernel.

At some point Isomorphic Javascript became the main reason to use it, as golang has largely stolen the non-blocking IO crown with its implementation of green threads.

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

#137

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

Nothing's perfect. Go's is Erlang's with a shared memory model. That creates a lot of trade offs and limitations. In some places, it's a perk. In others, it's not.

No such thing as perfect, only trade offs.

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

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

I don't think npm became the biggest package repository by accident so it is sure "well designed".

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

#139
post #98

Earlier quoted context omitted.

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.

That's exactly the point and what people are missing. If you used Twisted you didn't have access to the entire Python ecosystem and there was a lot of work that was required to get standard packages to work in a non blocking way.

Also callbacks for all that they're derided now were an easy paradigm to understand to get into the whole philosophy of async. The first prototypes of node supported different paradigms before callbacks were settled on IIRC.

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

#140
post #88
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?

Any language that uses the actor model for concurrency which is basically every language created in the last decade. Elixir, GO, Akka framework for Java and C#, Pony, Dart, Erlang, ELM, SCALA, ...
Post reply on HN