Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js - A Giant Step Backwards

fenn.posterous.com

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Node.js - A Giant Step Backwards

#101

Post by moe »

Cushman wrote: post #99
moe wrote: post #98

Earlier quoted context omitted.

And now the cost of hosting a hundred webapps is just a rounding error in contrast to the cost of developing one. That's a weird way to look at it, unless you're in the webapp hosting business? For everyone else there is usually only one webapp that they care about. I can take the same program and handle 20,000+ concurrent users on two servers Sorry to break it, but that's not how it works. Unless you have one of tho…

Really? Show of hands, now, who here cares about one (and only one) webapp? Anyway, what's good for the webapp hosting business is good for web developers, and what's good for web developers is good for the technical ecosystem in general (and then the world). Of course going from VPSes to EC2s was a significant improvement. But that isn't as good as it gets . EC2 rates were cheap already, but when Az started the free…

This is a way of making programs run faster, and not a little faster, but a hundred times faster.

Sorry, but if anything then that statement is absurd.

Faster than what? And where's that "hundred times faster" figure coming from?

It seems there's a bit of a misconception about the bottlenecks and cost structure in real world web applications.

Rails (aka the slowest web framework known to man) is popular because it trades hardware for development velocity. Hardware is cheap, developer salaries are not.

Re: Node.js - A Giant Step Backwards

#102

Post by Cushman »

moe wrote: post #101
Cushman wrote: post #99

Earlier quoted context omitted.

Really? Show of hands, now, who here cares about one (and only one) webapp? Anyway, what's good for the webapp hosting business is good for web developers, and what's good for web developers is good for the technical ecosystem in general (and then the world). Of course going from VPSes to EC2s was a significant improvement. But that isn't as good as it gets . EC2 rates were cheap already, but when Az started the free…

This is a way of making programs run faster, and not a little faster, but a hundred times faster. Sorry, but if anything then that statement is absurd. Faster than what? And where's that "hundred times faster" figure coming from? It seems there's a bit of a misconception about the bottlenecks and cost structure in real world web applications. Rails (aka the slowest web framework known to man) is popular because it tr…

It's cheap until it's not. At a certain point, you just can't process more requests at once in Rails. That's your limit. And it's not much— 100, maybe.

But node multiplies that, a lot. Which is nice, because you know it won't break or slow down if a bunch of people use it for some reason. And so you don't have to re-architect your system for a while longer, which is valuable time.

Re: Node.js - A Giant Step Backwards

#103

Post by pkulak »

amock wrote: post #3
pkulak wrote: post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

Have you tried Haskell? Why haven't you tried Erlang? They're both good choices for writing applications that handle making and receiving thousands of concurrents requests because they have very fast lightweight threads and good exception handling and you don't need to write the kind of code that Node.js forces you to write.

That's why I mentioned that I hadn't tried Erlang. It was one of my first choices, but the library support wasn't there. Tolerant HTML parsing is a requirement for the project, and there doesn't seem to be any good parsers for Erlang.

Re: Node.js - A Giant Step Backwards

#104

Post by pkulak »

sausagefeet wrote: post #8
pkulak wrote: post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

> I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed. I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and…

Known that what doesn't scale? Threads? Sure they do. I could have made Ruby threads work, I guarantee you. Move the network requests into a giant thread pool, and then do everything else synchronously. It was the context switching that was killing me, but you can use threads in such a way that that's not a problem. It's just a lot of work. More work than just using Node, which pretty much does exactly that for me for free.

And on a side note "your education has failed you"? Seriously? You can't just preface something with "I don't mean to be offensive" and then say whatever you like. I don't mean to be offensive, but get yourself some social skills.

Re: Node.js - A Giant Step Backwards

#105

Post by pkulak »

thristian wrote: post #69

It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier. To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what…

This is a great library for doing those sorts of things with Node: https://github.com/caolan/async

Re: Node.js - A Giant Step Backwards

#106

Post by OJ »

jacobmt wrote: post #56
nirvana wrote: post #18

If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…

> The reason is, there isn't something like node.js for erlang, and so I set out to fix that. That is not true, see: https://github.com/hookio/hook.io , been in development in Node.js for over two years.

hook.io sits on top of Node.js and deals with IO. How on earth does this relate to Nirvana's goal of having something like Node.js for Erlang?

Re: Node.js - A Giant Step Backwards

#107

Post by moe »

Cushman wrote: post #102
moe wrote: post #101

Earlier quoted context omitted.

This is a way of making programs run faster, and not a little faster, but a hundred times faster. Sorry, but if anything then that statement is absurd. Faster than what? And where's that "hundred times faster" figure coming from? It seems there's a bit of a misconception about the bottlenecks and cost structure in real world web applications. Rails (aka the slowest web framework known to man) is popular because it tr…

It's cheap until it's not. At a certain point, you just can't process more requests at once in Rails. That's your limit. And it's not much— 100, maybe. But node multiplies that, a lot. Which is nice, because you know it won't break or slow down if a bunch of people use it for some reason. And so you don't have to re-architect your system for a while longer, which is valuable time.

But node multiplies that, a lot.

Yes. Rails is measured in hundreds per second. Node in thousands per second.

The point that you still seem to be missing is that the monetary amounts involved have normally turned into a rounding error long before you reach a traffic-volume where this difference becomes relevant.

Or, in other words, hosting a "webapp" already is nearly free in terms of hardware.

Re: Node.js - A Giant Step Backwards

#108

Post by FooBarWidget »

sausagefeet wrote: post #96
FooBarWidget wrote: post #74

Earlier quoted context omitted.

> The fact that you even tried it and thought it might be a viable solution just shows your education has failed you This holier-than-thou attitude is exactly the thing that prevents more people from becoming educated on these kind of subjects. Knowledge and experience on these kinds of subjects are _not_ trivial and are _not_ easy to obtain! Information about what scales, what does not, and why, are scattered all ov…

If I told you that the Sun revolved around the earth, would you consider it holier-than-thou to tell me my education has failed me? The knowledge that the original solution (threads in Ruby for handling large numbers of concurrent connections) does not work is not a secret. Even with a peripheral following of Ruby it is well known that this solution would not work, not only is the base Ruby implementation slow but th…

If 99% of the world doesn't know that the Sun revolved around the earth, and knowledge of that fact is scattered across a handful of monks in obscure monasteries, then yes that would indeed be a holier-than-thou attitude. And that's exactly what's going on with scaling knowledge.

I would even argue that the Ruby threading problems he's experiencing may not necessarily because Ruby threads don't scale, but possibly because he's using them wrong or because he's not using the right version of Ruby. Ruby 1.8 uses select() to schedule I/O between threads so the more threads and the more sockets you have, the slower things become because select() is linear time. The use of select() also results in a hard limit of about 1024 file descriptors per Ruby 1.8 process. Also, context switching in Ruby 1.8 requires copying the stack. Ruby 1.9 is much better in this regard since it uses native threads and no longer uses select() to schedule threads that are blocked on I/O. I'm running a multithreaded, multiprocess Ruby (1.8!) analytics daemon that generates 12 GB of data per day. It flies. VMWare CloudFoundry's router is written in Ruby + EventMachine. That thing has to process tons and tons of requests and they've found Ruby + EventMachine to be fast enough. To simply say "Ruby doesn't scale and is slow" is too simplistic, and ignoring the underlying more complex reasons would result in one bumping against the same problems in a different context. So no, it isn't so obvious from day 1 that using Ruby would be a problem.

Re: Node.js - A Giant Step Backwards

#109

Post by sausagefeet »

pkulak wrote: post #104
sausagefeet wrote: post #8

Earlier quoted context omitted.

> I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed. I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and…

Known that what doesn't scale? Threads? Sure they do. I could have made Ruby threads work, I guarantee you. Move the network requests into a giant thread pool, and then do everything else synchronously. It was the context switching that was killing me, but you can use threads in such a way that that's not a problem. It's just a lot of work. More work than just using Node, which pretty much does exactly that for me fo…

I don't understand why saying your education has failed you is considered offensive. In the US we say that about high schoolers all the time but it's a knock on the education system not the students.

Re: Node.js - A Giant Step Backwards

#110

Post by IbJacked »

sausagefeet wrote: post #14
IbJacked wrote: post #13

Earlier quoted context omitted.

But, um, concurrently means "at the same time," too. Merriam's first definition is actually "running parallel." Wouldn't it be better to describe it as running serially, using non-blocking asynchronous function calls? Guess that doesn't really roll of the tongue, though.

In computer science the two terms are generally distinguished, while you're free to redefine them commonly when people say concurrency they refer to a model of performing things at the same time but may not actually be simultaneous. Parallelism is generally the actual act of it running simultaneously.

Fair enough, I was unaware of the common distinction in the CS domain.
Post reply on HN