Hacker News Reader

Comment by nevinera | Hacker News Reader

I'm pretty sure any evented framework in any language can do the same thing.

Even non-evented ones, the interesting part really is not node itself (despite what the blog says) but the ability to pipeline streams without having to touch every byte yourself.

It should be possible to do something similar using e.g. generators (in Python) or lazy enumerators (in Ruby)

In fact, in Python's WSGI handlers return an arbitrary iterable which will be consumed, so that pattern is natively supported (string iterators and generators together, then return the complete pipe which will perform the actual processing as WSGI serializes and sends the response). Ruby would require an adapter to a Rack response of some sort as I don't think you can reply an enumerable OOTB.

It's possible in Python generators but in my tests the performance sucks particularly if the client can't receive fast enough.

Using eventlet or gevent was much kinder to the system.

Ye, 100% true. I've spent many man-years writing entire systems like this in C and Java.

It's just in node, doing it in the evented way was actually simpler and quicker to implement, than the 'ghetto' way. This isn't usually the case, and I always recommend doing the simplest thing that works first. It's just nice here that the simplest thing is also a tight solution.

And what exactly does 'ghetto' mean here? You've used the same term in your blog post.

We use it to mean, the quick and dirty simple solution that we write first, and that is usually good enough but your a little embarrassed to admit. It's not the elegant or crafted, but works.

Our original solution was literally a shell exec, and it was perfectly fine (..for a while)

Given your definition, I'd probably try to use a different word.

Lots of people use "ghetto" to mean quick-and-dirty.

That's not an argument for it's continued use. I agree with rhizome, you should consider using a different word or phrase.

What is the connection between evented and streaming? It seems like a thread-per-request server would have to do exactly the same thing (except, they would not have to worry about giving back their event loop thread).

Evented streaming doesn't tie up a process waiting for specific data to come in. During the times that the process is waiting other things can get done (other streams processed, etc.).

With Node it's brain-dead easy and requires less code.

i.e. http://news.ycombinator.com/item?id=3753019

Reply on news.ycombinator.com