Is NodeJS Wrong? • Hacker News Board

Re: Is NodeJS Wrong?

#41

Post by wallfly » Mon, Mar 07, 2011, 3:58 PM UTC

The author mentions CPS...

There already exists a powerful cross-environment JavaScript CPS implementation called JooseX.CPS:

https://github.com/SamuraiJack/JooseX-CPS

Tutorials:

http://joose.it/blog/2011/02/14/joosex-cps-tutorial-part-i/

http://joose.it/blog/2011/02/22/joosex-cps-tutorial-part-ii/

If you're not familiar with the Joose object system (works great in browsers and node.js), you should give it a look: http://joose.github.com/Joose/doc/html/Joose.html

Also, CPS is not the only option for dumping callbacks in browsers / node.js. Another would be the Functional Reactive style. See Flapjax: http://www.flapjax-lang.org/

I'm working on a reimplementation of Flapjax right now: https://github.com/michaelsbradleyjr/Jolt

It's got Joose under the hood and I'm generalizing all the library functions for n-ary EventStreams and Behaviors (Reactive concepts). It's very much a work in progress and the test coverage is non-existant atm, but that's owing to the fact I'm working from an existing, working code base. As soon as I have all the core estream and behavior facilities in place, I'm planning to write some exhaustive tests that use JooseX.CPS together with the Joose3 author's Test.Run library: https://github.com/SamuraiJack/test.run

Re: Is NodeJS Wrong?

#42

Post by rduerden » Mon, Mar 07, 2011, 6:58 PM UTC

andrewstuart wrote: post #7

Can anyone suggest a better architecture than that of node.js for a server side Javascript application engine? Perhaps still using Google V8 but maybe being more intelligent about threading/multicore, maybe using something like gearman (gearman.org) to distribute tasks, and addressing some of the criticisms of node.js but still maintaining good performance.

perhaps http://n.odecs.net - still in it's infancy but being built in C# on mono and integrates with threading right off the bat

Re: Is NodeJS Wrong?

#43

Post by [deleted] » Tue, Mar 08, 2011, 12:55 AM UTC

jerf wrote: post #40

gruseom wrote: post #23

Earlier quoted context omitted.

I don't really understand your comment. No one's saying that IPC is unique to Node. The OP's criticism was: async i/o is fine, but what if you have some CPU-intensive work to do? Isn't it bad to let that block the whole server? Of course it is. OP's answer is a different server architecture; Nodians' answer is just forward that work to a different process and let Node keep doing the one thing it does well. Why use No…

"What other alternatives are there? (Twisted, EventMachine, ...?)" For every major high-level language, there is at least one Node-like library, and sometimes more than one (Perl has POE, Event::Lib, based on my experience the raw glib wrapper isn't half bad albeit perhaps not the fastest, but you get good access to anything else based on glib, in fact Perl has so many that there's an Any::Event wrapper to remove you…

[deleted]

Re: Is NodeJS Wrong?

#44

Post by gruseom » Tue, Mar 08, 2011, 4:19 AM UTC

jerf wrote: post #40

gruseom wrote: post #23

Earlier quoted context omitted.

I don't really understand your comment. No one's saying that IPC is unique to Node. The OP's criticism was: async i/o is fine, but what if you have some CPU-intensive work to do? Isn't it bad to let that block the whole server? Of course it is. OP's answer is a different server architecture; Nodians' answer is just forward that work to a different process and let Node keep doing the one thing it does well. Why use No…

"What other alternatives are there? (Twisted, EventMachine, ...?)" For every major high-level language, there is at least one Node-like library, and sometimes more than one (Perl has POE, Event::Lib, based on my experience the raw glib wrapper isn't half bad albeit perhaps not the fastest, but you get good access to anything else based on glib, in fact Perl has so many that there's an Any::Event wrapper to remove you…

I friendlily (!) request less anti-hype and more explanation of the technical issues, preferably with illustrations in code. For example, in the above post there is one point at which you come close to being specific and then back off, saying it's borderline obvious. It wasn't obvious to me.

There is one point at which I somewhat follow you. You say that the complexity introduced by callback management grows nonlinearly with program complexity. I understand this to mean that logic organized into async callbacks isn't composable (you have to write new logic to implement the composition, as opposed to just applying some operator to combine them) and isn't orthogonal (if you want to call some code that's written this way, your code also has to be written this way, and each new layer gets harder to add). It's easy to see how this could rapidly get out of control. But I'm not convinced that it must. There may be designs that nip this complexity in the bud. For example, the work done by callbacks themselves could be kept to a minimum (and preferably be standardized, i.e. when i/o is received, store the result in some standard place). In this way the callback chains always return as quickly as possible. Of course then you need some parallel strategy for managing the control flow of the program itself - some sort of state machine, perhaps.

Perhaps this is greenspunning Erlang but if so I'd like to know how.

Re: Is NodeJS Wrong?

#45

Post by jaekwon » Tue, Mar 08, 2011, 6:23 PM UTC

beagle3 wrote: post #22

silentbicycle wrote: post #9

Earlier quoted context omitted.

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all . It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s . I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unl…

> Still, most libraries are blocking* > * Which is a funny objection, like being > mad that most libraries default to using > decimal numbers rather than octal. It must > be a conspiracy! Actually, there _is_ a distinction here: It is ridiculously easy to implement blocking semantics on top of non-blocking semantics - in some pseudo code: event = do_async(); pause_until_completion_or_error(event) Whereas implementing…

This may surprise some, but implementing blocking semantics on top of non-blocking semantics in node.js is impossible.

Re: Is NodeJS Wrong?

#46

Post by jaekwon » Tue, Mar 08, 2011, 6:33 PM UTC

gruseom wrote: post #44

jerf wrote: post #40

Earlier quoted context omitted.

"What other alternatives are there? (Twisted, EventMachine, ...?)" For every major high-level language, there is at least one Node-like library, and sometimes more than one (Perl has POE, Event::Lib, based on my experience the raw glib wrapper isn't half bad albeit perhaps not the fastest, but you get good access to anything else based on glib, in fact Perl has so many that there's an Any::Event wrapper to remove you…

I friendlily (!) request less anti-hype and more explanation of the technical issues, preferably with illustrations in code. For example, in the above post there is one point at which you come close to being specific and then back off, saying it's borderline obvious. It wasn't obvious to me. There is one point at which I somewhat follow you. You say that the complexity introduced by callback management grows nonlinea…

From my experience with Node.js, your interpretation is correct. I also share your optimism for finding a general solution to this problem, but that's exactly what jerf said isn't worth the complexity once you implement it.

Even if you do manage the callback complexity issue, there is still the issue of exception handling, which jerf also explains here: http://news.ycombinator.com/item?id=2150800

That said, jerf hasn't proven that trying is not a rite of passage. Sorry for the double negative.

Re: Is NodeJS Wrong?

#47

Post by gruseom » Tue, Mar 08, 2011, 11:17 PM UTC

jaekwon wrote: post #46

gruseom wrote: post #44

Earlier quoted context omitted.

I friendlily (!) request less anti-hype and more explanation of the technical issues, preferably with illustrations in code. For example, in the above post there is one point at which you come close to being specific and then back off, saying it's borderline obvious. It wasn't obvious to me. There is one point at which I somewhat follow you. You say that the complexity introduced by callback management grows nonlinea…

From my experience with Node.js, your interpretation is correct. I also share your optimism for finding a general solution to this problem, but that's exactly what jerf said isn't worth the complexity once you implement it. Even if you do manage the callback complexity issue, there is still the issue of exception handling, which jerf also explains here: http://news.ycombinator.com/item?id=2150800 That said, jerf hasn…

Not a general solution. An app-specific solution. That is, I don't want a framework; I just want a consistent simple design for an individual app written in this style. That's a big difference.