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

51–60 of 124 posts

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

#51

Post by philjackson »

jerf wrote: post #47
philjackson wrote: post #36

Earlier quoted context omitted.

"it's really easy to accidentally write something that blocks badly" What is this nonsense? Isn't it time we knock this one on the head? Let me let you into a secret: If you write CPU intensive enough code in any framework you can eventually block all further requests. This whole debate was based on FUD and a complete misunderstanding of what node is all about. Read the previous posts and don't post generic, bullshit…

"If you write CPU intensive enough code in any framework you can eventually block all further requests." "Intensive enough" is a vague and fuzzy term which you can hide too much behind. So let me put it this way: Go grab Yaws, the Erlang web framework. Write a web page that goes into an infinite loop. Write some other web pages that work normally. Observe that visiting the infinite-loop web page once does not cause t…

But who deploys node in a single instance? There's documentation all over the place which tells you how to load balance over several instances - and it's easy to do so. This is my point, the node is cancer article was pure troll.

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

#53

Post by InclinedPlane »

vogonj wrote: post #24
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…

you realize that you're just making Ted's point for him from the opposite direction, right? his point, when you look behind the trolling, is that node.js is not magical special sauce and that shitty coders who write poorly-scaling code will be shitty coders who write poorly-scaling code no matter what technology they use -- the "cancerous" properties of node arise simply because of the amount of groupthink that pitch…

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.

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

#54

Post by jcdavis »

jamwt wrote: post #52
jcdavis wrote: post #48

Earlier quoted context omitted.

Sure it is. Stack space isn't free

It is with TCO.

How exactly is the particular implementation in question tail-call optimized? Honest question, not trying to be snarky. I'm well aware that fib can be done to use TCO, but this doesn't appear to do so

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

#55

Post by jerf »

philjackson wrote: post #51
jerf wrote: post #47

Earlier quoted context omitted.

"If you write CPU intensive enough code in any framework you can eventually block all further requests." "Intensive enough" is a vague and fuzzy term which you can hide too much behind. So let me put it this way: Go grab Yaws, the Erlang web framework. Write a web page that goes into an infinite loop. Write some other web pages that work normally. Observe that visiting the infinite-loop web page once does not cause t…

But who deploys node in a single instance? There's documentation all over the place which tells you how to load balance over several instances - and it's easy to do so. This is my point, the node is cancer article was pure troll.

OK. Set up a load balanced infinite loop. Result: A load balanced infinite loop. This is not a win for Node. Load balancing across a number of hung processes buys you very little. (Not quite zero; you get a chance to detect the fact that it's hung and restart it, as long as these pathological requests aren't coming in fast enough. Hope the user who poked the bug doesn't hit refresh too many times!)

I still think you may not understand what modern schedulers end up doing here.

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

#56

Post by DrHankPym »

wpeterson wrote: post #31

The only difference in this implementation is that it uses memory-based caching (memoization) to compute given value once and then serve the cached copy. Of course this is fast for 1000 iterations, since the effective cost is zero from the second request. People really are misunderstanding the critique of fibbonacci as representing any CPU intensive task. TLDR; All the author did here was remove the CPU intensity by…

I'm actually very confused by his criticism. You can write a CPU intensive task in any language, and you'll have the same problem.

Or is that the point? Some people believe Node.js will magically make all processing computations = 0? I'm all for discouraging the rumor that Node.js will solve every problem, but don't call it Cancer.

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

#58

Post by scooty-puff »

wmf wrote: post #28
mattlong wrote: post #12

Earlier quoted context omitted.

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

Check out the Cilk version, which is not only concurrent but parallel as well: http://myxman.org/dp/node/182 I agree with jerf that either you shouldn't have to worry about splitting your computation at all or at least you should have syntactic sugar for it. The Node solution has much more noise than code.

http://hpaste.org/52108

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

#59

Post by vogonj »

vogonj wrote: post #24
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…

you realize that you're just making Ted's point for him from the opposite direction, right? his point, when you look behind the trolling, is that node.js is not magical special sauce and that shitty coders who write poorly-scaling code will be shitty coders who write poorly-scaling code no matter what technology they use -- the "cancerous" properties of node arise simply because of the amount of groupthink that pitch…

to expand upon this, here are some other representative Ted Dziuba posts:

http://teddziuba.com/2010/10/taco-bell-programming.html

http://teddziuba.com/2011/02/the-case-against-queues.html

http://teddziuba.com/2011/03/osx-unsuitable-web-development....

http://teddziuba.com/2008/09/a-web-os-are-you-dense.html

if I had to sum up his philosophy in three sentences, here they are:

your job is software engineering. every bit of fancy shiny stuff that you add onto your software is another thing that can break. the most important decision you need to make in your job is determining when your tools are good enough and don't need further elaboration -- at a certain point you need to stop jerking off about your toolchain, and just ship your project.

Post reply on HN