Node.js cures cancer • Hacker News Board

Re: Node.js cures cancer

#71

Post by christkv » Mon, Oct 03, 2011, 9:52 AM UTC

ittayd wrote: post #62

zohebv wrote: post #41

Earlier quoted context omitted.

Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests betwee…

The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU. Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations

Most web applications are io bound not cpu bound as they spend most of their time talking to other systems across the network like your db or queue or some rest service. the cost of spinning up threads is memory and context switches by the os. Async is just a way to avoid this for io operations. Node.js is just an incredibly convenient way of doing this as there are less ways of shooting yourself in the foot than if you apply the async patterns to other tech platforms.

Cpu bound is still cpu bound on any tech platform and needs another strategy to deal with it. I think it's better to look at node.js as a tool in your toolbox that is well adapted to running high load web-services and apps that are io bound instead of a swiss army-knife that does everything great.

But as any toolbox you need more tools in the box to be a good carpenter. That includes picking tech that can do the cpu bound stuff in a appropriate manner, be it java, scala, c++, erlang whatever. You don't write a graph database in node.js unless you are masochistic. Just as you hopefully don't write an async server in assembly.

From my usage perspective node.js is great for my async needs and the low resource usage means I need less hardware to scale my typical web app.

Re: Node.js cures cancer

#72

Post by hampusw » Mon, Oct 03, 2011, 9:58 AM UTC

tedjdziuba wrote: post #20

exogen wrote: post #17

Earlier quoted context omitted.

One Node process is reduced to doing the trivial work, like you'd have in any other system. Nothing is preventing the other processes from also being Node.

True, and in fact, this is how nginx works: the process that owns the event loop is separate from the process(es) that does the work. This is a decent way of mixing an event loop and multi-core processing, but with Node, you're forced to marry the HTTP server to the application, which is a dangerously tight coupling of responsibilities. If you really want to do something silly like write your application in server-si…

There's nothing keeping you from running a separate web server and then proxying requests to Node using HTTP. Why is it a problem that you do this using HTTP? What alternative protocol would be so much better? FastCGI isn't really that different (each have their pros and cons) and CGI has obvious problems...

WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).

Re: Node.js cures cancer

#73

Post by LeafStorm » Mon, Oct 03, 2011, 10:57 AM UTC

    try:
        my_var
    except NameError:
        pass
    else:
        if my_var is not None:
            # Ted needs better examples
            ...

When would you EVER need to use this code? There is no situation in which you should ever need to use a variable in Python that may or may not be defined. While Ted's example may seem like a cheap shot, it does highlight an important problem with JavaScript: all the craziness with regards to types that aren't "real" types like undefined, arguments, and Array.

Re: Node.js cures cancer

#74

Post by wyuenho » Mon, Oct 03, 2011, 10:58 AM UTC

Is it just me or is Brian Beck misunderstood Python idioms? What's with the try/except block? There's no auto-vivification in Python. So you just don't try to catch a NameError. You just let it blow up in your test and fix your code afterwards. I'm really tired of these straw man examples.

Re: Node.js cures cancer

#75

Post by wyuenho » Mon, Oct 03, 2011, 11:07 AM UTC

LeafStorm wrote: post #73

try: my_var except NameError: pass else: if my_var is not None: # Ted needs better examples ... When would you EVER need to use this code? There is no situation in which you should ever need to use a variable in Python that may or may not be defined. While Ted's example may seem like a cheap shot, it does highlight an important problem with JavaScript: all the craziness with regards to types that aren't "real" types…

I was thinking about the same thing. There's no auto-vivification in Python. Thing just blow up and you fix your code. You NEVER do this in real Python code. I'm tired of straw man examples...

Re: Node.js cures cancer

#76

Post by wyuenho » Mon, Oct 03, 2011, 11:13 AM UTC

zohebv wrote: post #41

tedjdziuba wrote: post #5

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…

Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests betwee…

How is running 40 instances of node processes different from running 40 instances of a single threaded web server? How is running 40 instances of single threaded event loops better than running 10 instances of a process with 4 threads each? If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? Threads are too hard to program to? Try STM? I'm not buying the notion that node's event model has any advantage over anything whatsoever. Try Erlang if you want a properly engineered, event-driven development environment.

Re: Node.js cures cancer

#77

Post by wyuenho » Mon, Oct 03, 2011, 11:17 AM UTC

christkv wrote: post #71

ittayd wrote: post #62

Earlier quoted context omitted.

The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU. Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations

Most web applications are io bound not cpu bound as they spend most of their time talking to other systems across the network like your db or queue or some rest service. the cost of spinning up threads is memory and context switches by the os. Async is just a way to avoid this for io operations. Node.js is just an incredibly convenient way of doing this as there are less ways of shooting yourself in the foot than if…

True, but wouldn't just making IO async be enough?

Re: Node.js cures cancer

#78

Post by sannysanoff » Mon, Oct 03, 2011, 12:18 PM UTC

I wonder if

1) node.js async i/o is any different from haskell i/o? 2) author knows something about strongly-typed languages, or he deliberately banned them those from server side? Imho, dziuba tried to drop a hint about strongly-typed languages, not python or ruby.

Re: Node.js cures cancer

#79

Post by dewiz » Mon, Oct 03, 2011, 12:20 PM UTC

dewiz wrote: post #46

how do you dare ? and why are you at the top ? really disappointed

I'd really like to know why people like to joke on cancer and downvote people which might be hurt by these stupid titles.

Re: Node.js cures cancer

#80

Post by dewiz » Mon, Oct 03, 2011, 12:22 PM UTC

I just hope you will never have to experience what cancer is, otherwise you will understand how important a "cure" could be.