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

71–80 of 124 posts

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

#71

Post by mhd »

vogonj wrote: post #65
InclinedPlane wrote: post #64

Earlier quoted context omitted.

Right, let's just stop talking about cool new technologies since some people might misuse them. Does anyone want to help me debug my webapp? It's written in C.

nice strawman. my point isn't that you shouldn't build up buzz. it's that, when buzz exists around something, your job as a platform implementor includes making people aware of the things your product can't do well, and pitfalls the end-user might run into. saying "well, it's their own fault for not being clueful enough to know what they were doing wrong, this technology is for pro hackers only !" is developer-hostil…

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 cluelessly elitist or giving the unwashed masses false hope?

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

#72

Post by tedjdziuba »

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…

I like you.

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

#73

Post by [deleted] »

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…

[deleted]

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

#74

Post by ldh »

glenjamin wrote: post #62
mark242 wrote: post #57

Note to Ted: next time, just use sleep().

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…

Doesn't that kind of take the wind out of Node's sails as far as its claims of being easier for dummies to write non-blocking code, if you have to do all the usual due diligence anyway?

I'm genuinely curious as someone who's only familiarity with Node is hype and through hearing the adjective "evented" thrown around with wild abandon lately.

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

#75

Post by Detrus »

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.

But is the async module itself elegant? I guess it's relative, it's even less elegant not to use the module. The async module is still a hack, the cleanest one Node has.

I think the whole discussion about "cancer" wouldn't have happened if the V8 team added continuations by now. They mentioned that they will so we might be cleaning up big chunks of code.

It's funny how a tech can get so popular with these big warts. Probably because people use it in a very limited way, no one writes CPU intensive code because you rarely need it for serving sites and data. Then the clumsy callbacks aren't so bad.

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

#76

Post by mark242 »

glenjamin wrote: post #62
mark242 wrote: post #57

Note to Ted: next time, just use sleep().

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 that the HTTP server isn't the same entity doing the application work."

..which has basically been true ever since mod_jk was created.

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

#78

Post by vogonj »

mhd wrote: post #71
vogonj wrote: post #65

Earlier quoted context omitted.

nice strawman. my point isn't that you shouldn't build up buzz. it's that, when buzz exists around something, your job as a platform implementor includes making people aware of the things your product can't do well, and pitfalls the end-user might run into. saying "well, it's their own fault for not being clueful enough to know what they were doing wrong, this technology is for pro hackers only !" is developer-hostil…

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, including robust facilities for concurrent/non-blocking I/O". nothing marketing-y about non-blocking I/O or a given programming model making a language intrinsically "fast" or scalable, like nodejs.org's:

"This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. [...] Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems."

in addition, node.js is in a little bit of a weird position of introducing a whole new language environment for an existing programming language, since node.js is effectively the vanguard of server-side/concurrent Javascript: I'd hope for an official series of tutorials designed to introduce the nonprogrammer, or "Web app-only programmer" of Javascript, to concurrent programming in the large.

that said, the node community might already be doing things like this which aren't obvious to the layman, and if so, good on them. good concurrent programmers are hard to find, and anything that encourages people to learn how to do concurrency well is a good thing.

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

#79

Post by DrHankPym »

burgerbrain wrote: post #67
DrHankPym wrote: post #56

Earlier quoted context omitted.

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.

The issue is what happens when you write that CPU intensive task. If you do it in idiomatic Go, that same server will keep on responding to other requests in the meantime. With Node.js, that is not the case. You have to do things like, well, what this article does, to get it to work.

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.

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

#80

Post by corysama »

knieveltech wrote: post #23
rkalla wrote: post #20

As much as this whole Ted-gate thing has turned into a amped up argument of sorts, there has been a significant amount of knowledge for everyone shaken out of the trees about node.js as a result. Take for example this implementation, how many people getting started with node knew about async or memoization? Could be just me, but I learned a lot about what not to do and how to do certain things more efficiently with n…

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/
Post reply on HN