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

111–120 of 124 posts

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

#111

Post by willvarfar »

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…

Right. If Ted-gate was advocating using go or erlang I'd be so cool with everything except his choice of language.

But he wanted us to go back to CGI folks...

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

#112

Post by prodigal_erik »

jrockway wrote: post #100

This is the wrong approach. The right approach is to write your computationally-intensive code so that it runs in another process, and then to talk to that process over the network. Network servers must only talk to the network.

If I have unused capacity, I can afford simpler threaded code. If I'm overloaded, I need some other platform for the real work. It sounds interesting but unless I need to write my own software load balancer, I'm not sure what node (as implemented today) is appropriate for doing.

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

#113

Post by robinduckett »

ltbarcly3 wrote: post #98

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

Node.js can be done in different ways to this, the fact is, that this code works asynchronously, and this is how Node does async.

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

#114

Post by tef____ »

DougBTX wrote: post #66
vogonj wrote: post #59

Earlier quoted context omitted.

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

Any decent troll needs a nugget of truth at the bottom to hook people in.

It is an old question 'How do we tell truths that might hurt?'.

If you try the well reasoned analysis, you get passed over. It turns out that no-one pays attention unless there is a fight happening (c.f. tech crunch's reporting style)

'If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you.'

The morale is - everyone admonishes a flame, but nothing else gathers posts quite like it. If you think something is terrible, holding back will get you nowhere.

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

#116

Post by wisty »

vogonj wrote: post #59
vogonj wrote: post #24

Earlier quoted context omitted.

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

Fine. So you pick your tool (Java, Python, Node.js, presumably with an Nginx or Apache front end, though I'm not sure you want to put Node behind Apache), and use it.

I don't see how Node.js isn't a valid tool. Async can be a bit of an over-optimization, but you don't have to use it (even in Node), as Ted's naive Fib server shows. And Javascript is ugly as sin. But so's PHP, the language behind Wikipedia, and you have to use JS (or something like Coffee-script) anyway.

I don't know enough about Node to really judge it, but there's nothing I've heard in this whole flame-war that really rules it out.

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

#117

Post by amit_heroic »

Any tool in the wrong hands, is dangerous. So anyone trying to prove that fib makes node slow, is stupid. Node.js was made to make memory requests unblocking; not to generate the fib series for you.

Trying to nail a hammer with a drilling machine, is not to take yo anywhere.

Peace.

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

#118

Post by ovi256 »

apgwoz wrote: post #34
ovi256 wrote: post #13

Earlier quoted context omitted.

I think it'a a valuable tutorial to show node.js idioms. It's pretty easy to read, but I for one would struggle to write it as concisely.

Oh god, I hope you're joking.

I have to agree with you, I guess it only shows how little I know node.js

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

#119

Post by burgerbrain »

willvarfar wrote: post #111
burgerbrain wrote: post #83

Earlier quoted context omitted.

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…

Right. If Ted-gate was advocating using go or erlang I'd be so cool with everything except his choice of language. But he wanted us to go back to CGI folks...

To be clear, CGI doesn't exhibit the issues seen with Node either, it's issues are elsewhere (and separately debatable).

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

#120

Post by SaltwaterC »

mark242 wrote: post #76
glenjamin wrote: post #62

Earlier quoted context omitted.

To which the response is the same: simply don't block the event loop and use setTimeout. The whole cancer thing is based on the premise that blocking the event loop is unavoidable. I'm attempting to say that it isn't. Jerf's points about how it can happen accidentally are perfectly valid, it's up to the developer not to do something stupid and to actually have decent tests and benchmarks in place - as it would be wit…

CPU speed and bus speed is finite on the machine you're running on. Using setTimeout to poll the results of some thread you've spawned to run a calculation is _worse_ performance than just blocking in the first place, because now when you try to profile your application (how does one do that in node.js, anyways?) you're going to be looking at a million setTimeout closed loops. Here's Ted's entire point: "The point is…

The point is moot. HTTP is just the transport protocol in this case. Doesn't have to say that it has to be the front end service that talks to the end user web browser. The OP of the "cancer" article made up that shit. I can bind the listener of a node service to an UNIX Domain Socket and talk HTTP over that socket with a front end web server, instead of plain TCP (reduces the IPC latency). It is IPC between distinct components. It delegates the dynamic page generation to another service. It is a text interface, although sometimes, well, most of the times, the binary protocols outperform the text based protocols therefore the theory is crap. Isn't this "UNIX way" enough for some people? Forget the part that says: any IPC adds extra latency to the request - response paradigm aka the opposite of the stuff a web stack should do.

Can you tell me at least one example from the myriad xGI protocols for interfacing a web server with an application server that actually brings any benefit over having plain HTTP/1.1 and a reverse proxy? Does it help to have yet another protocol for doing basically the same task: IPC between a couple of servers? Any xGI client (aka web server) is basically a reverse proxy for an IPC protocol. Does it say somewhere, carved in stone, that this protocol must be other than HTTP? I think that most people that spend the time engineering yet another xGI solution simply don't see the forest for the trees.

PS: nobody stops anybody to drop a scgi.js or fastcgi.js module for node.js if that keeps people warm at night. But maybe I'm one of those tired of this shit: engineering yet another xGI protocol for every programming language that floats around the web. NIH syndrome, I'd say. At least HTTP is ubiquitous, while most servers already HAVE a reverse proxy handler.

Post reply on HN