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

181–190 of 235 posts

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

#181

Post by mattschmulen »

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

All this and the developers that were driving new line of biz products were coming from the front end ( web and mobile ), of course all front ends need backends and when these these folks went looking they naturally leaned toward JavaScript the same language they were using on the front end and Async model

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

#182

Post by mbrock »

gaius wrote: post #102
mbrock wrote: 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.

I don't want to ask everyone to install a native app, I don't want to use several different native app UI libraries, etc. I'm one of those people who thinks that the web browser as an app platform is a pretty good idea.

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

#183

Post by lenkite »

gaius wrote: post #102
mbrock wrote: 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.

Nobody likes to download and install stuff. Just imagine the state of the web if you had to install a app for every website you visit ? Oh...you need to add iOS and Android to the list of platforms. That makes it 5 platforms. 5x the work.

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

#184

Post by jonnycoder »

disordinary wrote: post #142
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…

V8 is not dirt slow. You may dismiss benchmarks where Node looks good as "invented" but there are countless real world examples of people moving from other languages to node and experiencing a huge speed increase. I know of one startup that had a fortune 500 company sign up to their service and their dotnet APIs couldn't hold the load and the cost of scaling them wasn't sustainable. They rewrote the hardest hit APIs…

You are spot on as I have been developing in node for the past 2 months. Coming from doing python and c# in the past, I picked up the asynchronous nature + promises and their "gotchas" within a few days of writing and rewriting an activemq module. All of our other requirements/stories have been developed at such a high speed relative to my past projects. Combined with docker and a QA team that writes automated tests with postman and protractor, our continuous integration is at a high maturity level.

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

#185

Post by lackbeard »

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?

Go, Erlang, Elixer, Haskell, Clojure, Scala.

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

#186

Post by bryanrasmussen »

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…

There were lots of ways to run JavaScript on the server before Node, however all the ways I am familiar with suffered from having either poor support, poor performance, or being marginally difficult to get to work.

JavaScript on the server before Node was a second-class solution.

On edit: so yeah, a nice way.

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

#187

Post by jabl »

pcwalton wrote: post #62
jgrahamc wrote: post #3

Earlier quoted context omitted.

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

AFAIU a lot of the complexity and slowness of "traditional" M:N threading approaches were due to the requirement to follow POSIX semantics (signal handling, preemptivity, etc.) within a purely library/OS based approach (no changes in the code generated by the compiler).

If you're doing a green threads implementation for a high level language runtime, those restrictions don't apply, to an extent. I think e.g. Erlang, Haskell or Go are examples of "green threads done right".

(Now, I do think Rust did the right thing in getting rid of green threads, but that IMHO is more a result of the space Rust is in rather than a general indictment on the utility of green threads)

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

#188

Post by ngrilly »

pcwalton wrote: post #62
jgrahamc wrote: post #3

Earlier quoted context omitted.

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

I'd suspect NGPT was abandoned because they couldn't use growing stacks while staying compatible with C calling convention (but I wasn't able to find any confirmation of this by googling). Go doesn't have this issue because it uses another calling convention.

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

#189

Post by pcwalton »

ngrilly wrote: post #188
pcwalton wrote: post #62

Earlier quoted context omitted.

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

I'd suspect NGPT was abandoned because they couldn't use growing stacks while staying compatible with C calling convention (but I wasn't able to find any confirmation of this by googling). Go doesn't have this issue because it uses another calling convention.

Stack growth is orthogonal to the M:N vs. 1:1 distinction. You can have large stacks with M:N or small stacks with 1:1.

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

#190

Post by pcwalton »

jabl wrote: post #187
pcwalton wrote: post #62

Earlier quoted context omitted.

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

AFAIU a lot of the complexity and slowness of "traditional" M:N threading approaches were due to the requirement to follow POSIX semantics (signal handling, preemptivity, etc.) within a purely library/OS based approach (no changes in the code generated by the compiler). If you're doing a green threads implementation for a high level language runtime, those restrictions don't apply, to an extent. I think e.g. Erlang,…

Go still has a lot of issues around the inability to preempt except at function call boundaries, which is an issue that doesn't exist in 1:1 threading. Fairness and priority inversion are likewise issues with M:N that apply equally well to Go's implementation. Signal handling is too, although any GC language pretty much has to sacrifice POSIX signal handling already...

Green threads done right strikes me as something like Windows' user mode scheduling (or Google's switchto patch that sadly never made it upstream), in which threads really are 1:1 as far as the kernel is concerned, but manually scheduled by userspace. This requires kernel support, but it fixes every issue except preemption, which is better to just not fix. (Few Go programs actually benefit from multicore CPU scaling; for CPU bound tasks a better use of optimization time is just not writing in Go, which tends to result in better speedups than trying to scale Go due to Go's compiler being relatively immature.)

In my ideal world, kernel-scheduled and user-scheduled threads would exist in the same language, and programmers could choose which one they want on a thread-by-thread basis. I/O calls would be equally compatible with either threading model (which could be done in a zero-overhead fashion with the proper kernel support), eliminating the problem of sync/async incompatibility. This can only really be done today on Windows, unfortunately...

Post reply on HN