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

Node-fib: Fast non-blocking fibonacci server

github.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Node-fib: Fast non-blocking fibonacci server

#91

Post by Peaker »

jerf wrote: post #17
glenjamin wrote: post #8

Author here, didn't really expect this to get picked up anywhere but since it has I'd like to point out the idea was to demonstrate that computationally expensive algorithms can be split across multiple iterations of the event loop to avoid blocking it. In this case concurrent requests take advantage of each others' memoisation, which would be somewhat trickier to do with threads as you'd probably need to worry about…

Yes, you too can by required by the compiler to implement cooperative multitasking by hand. In 2011. Yes. It is an answer to the criticism made, and I acknowledge that. But it is not a very good answer to the objection. The better answer is "don't do that in Node.js", which is still not all that great (it's really easy to accidentally write something that blocks badly), but is better.

Cooperative multitasking will always have the blocking problem, whether implemented manually or by the language. The manual callback chaining is tedious, though.

Preemptive multitasking solves that problem, but if mixed with lots of shared mutable state, it reintroduces much worse problems of non-determinism and unreproducible bugs.

The golden path involves preemptive multitasking with little-to-no shared state. That way you get to have your cake (determinism) and eat it too (no blocking problems/starvation).

Re: Node-fib: Fast non-blocking fibonacci server

#92

Post by vogonj »

freshhawk wrote: post #90
InclinedPlane wrote: post #53

Earlier quoted context omitted.

Personally I've never seen node.js pitched as a solution for newbies or sub-par coders toiling away in the enterprise trenches. I've always seen it marketed as a useful tool for people who know WTF they're doing.

Really? I've almost never seen node.js pitched to anyone other than newbies (although not in the enterprise trenches for sure). Rarely the pitch involves being able to share libraries between the server side and browser side (wonderful benefit of node.js) Most of the time it's being sold as "you already know javascript" or "it's super fast, because non-blocking is magic sauce!" I haven't used Node.js for anything ser…

I find the notion of sharing libraries between the client and server kind of odd, in that people who talk about the "open web" think it's a desirable quality.

it allows you to rev a protocol faster, but at the cost of not being forced to have a point of reference that isn't also intrinsically tied to one implementation of the protocol, which seems a very un-open thing to do to me.

Re: Node-fib: Fast non-blocking fibonacci server

#93

Post by DrHankPym »

burgerbrain wrote: post #83
DrHankPym wrote: post #79

Earlier quoted context omitted.

I'm still not getting it. Go might be able to handle an extra request or two for high CPU intensive tasks, but it will inevitably suffer the same consequence of locking all it's processes given enough requests. Still doing anything that is CPU intense on that layer is stupid in the first place.

A so called 'goroutine' locking up will not lock up the rest of that server. Other pages will still be served by that server. This has nothing to do with the efficiency of the underlying language, it has to do with Go doing cooperative multitasking transparently . It might as well be a separate process (in fact, for all you really know it could be). The code seen here does cooperative multitasking explicitly . It is…

Well, that just makes me more confused, because most languages I know handle multitasking explicitly, and they can all be dangerous when programmers exaggerate "cpu intensive" processes. I appreciate you trying to explain this guy's expectations, but I can't help but see this all as trolling FUD.

Re: Node-fib: Fast non-blocking fibonacci server

#95

Post by zoips »

vogonj wrote: post #78
mhd wrote: post #71

Earlier quoted context omitted.

Being a wee bit pessimistically inclined, I somewhat agree with the assessment of the node.js programmer pool (seems similar to the first migration of PHP programmers to Ruby after the infamous RoR screencast), I find it hard to attribute to this to the developer(s). Or in other words, a) what did they do wrong? b) What do you think would be the best way to "spin" a new platform like that without either being clueles…

disclaimer: I'm not a node.js expert by any means, and most of my day's work is on client code written in system programming languages (C and C++.) that which isn't, is in C#. I don't know of anything in particular that they're doing wrong because I don't really keep in touch with that particular PL community. that said, my ideal pitch page would contain something to the effect of: "extensive standard library, includ…

Node is marketed towards people with Javascript experience to a large degree, it seems to me (I could be wrong). People with Javascript experience more than likely have it via writing for a browser. A browser functions functions identically to Node: the event loop. So, those coming from writing Javascript in a browser will merely carry through their knowledge of development practices to Node, meaning they intrinsically will write event based code.

Or at least that line of thought makes sense to me.

Re: Node-fib: Fast non-blocking fibonacci server

#96

Post by rubyinghana »

bascule wrote: post #32
glenjamin wrote: post #8

Author here, didn't really expect this to get picked up anywhere but since it has I'd like to point out the idea was to demonstrate that computationally expensive algorithms can be split across multiple iterations of the event loop to avoid blocking it. In this case concurrent requests take advantage of each others' memoisation, which would be somewhat trickier to do with threads as you'd probably need to worry about…

If I try to ask for a large number (say 1 million) I run out of RAM: $ node app.js FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory Somehow you're using O(n) RAM to do the calculation. Seems bad bro. This code is the epitome of roflscale

If you had brain, you would know that JavaScript only has 52 bits of integer precision. Anything bigger than Fib(~83) is not accurate number and waste of time in JS.

Re: Node-fib: Fast non-blocking fibonacci server

#97

Post by rhizome »

corysama wrote: post #80
knieveltech wrote: post #23

Earlier quoted context omitted.

Aahz's law The best way to get information on Usenet is not to ask a question, but to post the wrong information.

There's an xkcd for everything... http://xkcd.com/386/

Unfortunately, it's usually that one.

Re: Node-fib: Fast non-blocking fibonacci server

#98

Post by ltbarcly3 »

I think this proves Ted's point. Look at that code. It is ugly as sin. Since I'm not an expert at node.js, I can't follow what is going on at all. Plus, this is memoizing. That is just cheating, it doesn't matter how you implement the algorithm if it memoizes.

If the creator of this github repo is to be believed, implementing a 3 line algorithm in node, you must use 20 lines of intricate, ugly code. If that is the case, node.js IS cancer.

Re: Node-fib: Fast non-blocking fibonacci server

#99

Post by justin_vanw »

mattlong wrote: post #12
Detrus wrote: post #9

Too bad the code is so nasty

How so? IMHO, it's an elegant demonstration of the async module.

It's beautiful how node takes a 2 line algorithm and turns it into 20 lines of twisted magic, lest you block all your connections.
Post reply on HN