Hacker News Reader

Comment by dextorious | Hacker News Reader

There probably a middle step "we also wanted to play with the latest shiny technology", that's not mentioned.

looking at the spreadsheet, "shiny newness" seems to be "velocity"; it has the highest weight of all (twice the average).

i can only begin to imagine the conversations a year down the line:

- how did you decide this?

- we used a spreadsheet. science!

- so you weighted against the asynchronous approach that confused your developers earlier?

- actually, we put most weight on it being an exciting new technology.

- oh.

https://docs.google.com/spreadsheet/ccc?key=0AvBGESHWxhk2dHJ...

The state of the spreadsheet wasn't constant.

We played with the weights.

What I posted was just where it was left after a meeting 9 months ago.

Yes, we definitely weight against our feelings of how we failed to employee Twisted Python. This was our experience, are you suggesting we shouldn't consider our experiences when evaluating something?

It really came down to a choice between pursuing a JVM based system, and Node.js.

Yup, we probably did want to do something new. But guess what, its worked. I'm sure we would have haters the other direction if we were posting about how Node.js has failed us, but it hasn't, yet.

i'm surprised that you chose a technology so similar to one that you had problems with before. especially when the deciding factor seems to have been "it's exciting" rather than "it does the job well". yes, you can argue that "exciting" is important to attract a top-notch team, but then i am not sure why a top-notch team would have problems with twisted (and not have the same general issues with node).

how will node fix the issues you had with twisted?

Could you clarify what `Velocity', `Correctness' mean?

https://docs.google.com/spreadsheet/lv?key=0AvBGESHWxhk2dHJ2...

Id have to disagree with that myself. While node and mongodb are both "shiny" they are because they solve a problem that people have and offer solutions to problems that are very appealing. Including as i mentioned i blieve in another comment here that using node allows you to only have ot work with one language. Which is great. So its true that python has similiar technologies such as tornado and twisted. But if node works then why not just stick to one technology to have to maintain rather then multiple ones. Also node has a great community that is increasing. Many python libraries dont have this. Meaning really documentation. For example tornado has very little documentation.

"Id have to disagree with that myself. While node and mongodb are both "shiny" they are because they solve a problem that people have and offer solutions to problems that are very appealing. "

A lot of people use them for solving problems they DON'T have.

Lots of people use both Mongo and Node.js at ill-fated attempts at premature scaling (similar to premature optimization).

Again i will disagree with you on that. One of the benefits of node and why its becomingly increasingly popular is that it allows ease of development with the benefits of scale built in. So you dont have to worry about a steep learning curve for a simple application that only a few people will ever use. Or that youre framework is easy to develop with but what happens if it becomes popular. What then. This is even more the case with todays applicaitons which incrasingly are "api" based with the web framework portion being used just to serve the ajax code and for urls and whatnot. With node you get all of it together.

Also if node used some other language that wasnt a standard this might also be true. But again it uses javascript or coffeescript which is becoming more and more used all f the time. Even in mobile applications and gaming now with canvas. Obviously if you know python or ruby or php extremely well and can build whatever you need quickly with that then theres no reason not to. I was new to python so it wasnt a major switch for me.

Node is popular because the initial learning curve is so easy, but I think it's a bit deceiving. There's a considerable step up from writing a basic node app and building a full "real world" app.

When you first start out, you don't realize that flow control is going to be an issue, you don't realize that you're likely going to need to figure out how to do stream processing. Those aren't especially difficult to learn, but it's a delayed learning curve. You don't know that you'll need them until you run into a dead end. There are libraries/modules that help with that now, but it's not trivial to figure out which is needed (at least not for someone just getting started).

Node is an interesting tool, and I think it solves some issues elegantly. I think some people use it for projects it's not suited for, but that happens with every language/framework/tool.

> benefits of scale built in

You don't get scale from a tool. You get it from experience in knowing how to run scaleable systems, and architect scaleable algorithms / systems.

> it allows ease of development with the benefits of scale built in

How is scale "built in" to Node any more than any other modern language/runtime?

It's not - it's built out, actually.

"I want to scale my app on modern, multi-core computers. I know, I'll write everything so that it all runs in a single thread!"

I want to scale my app on modern, multi-core computers. I know, I'll write everything so that it all runs in a single thread!

This is the same fallacy that gets repeated every time node is mentioned. If you're scaling up past a single machine you have to figure out how to share state between multiple machines anyway, so you may as well run a process per core. Then you have a single way to share state, rather than one way between cores and another between machines.

So unless you're writing a desktop app that needs to scale up but only to all of the cores of a single machine, you're sometimes better off simplifying the state-sharing logic.

You can get that all basically for free using something like ZeroMQ, without all the cancer, and with bindings for a Real Language.

Uh, that just proves my point that you don't need a multithreaded app to do so.

And your 'cancer' language is unhelpful. What are you afraid of? That somebody somewhere is using a bad language when a better one is available? That the NodeConf organizers reserved all of the good hotel rooms?

Why are you so angry at a programming community?

Here's what I'm afraid of: that the general cs understanding and quality of the programming community is sinking down the drain.

It's not like "somebody somewhere is using a bad language when a better one is available" is not hurting CS in general.

I don't think that node.js is doing either of those things. How does one quantify "sinking down the drain"? It's not zero-sum. How is Cloudkick writing services in javascript any worse or better than Cloudkick writing those services in python or java?

I think the real danger is people thinking they've learned everything there is to learn and closing their minds. Which includes telling people that "node.js is cancer". Node is letting people do all kinds of interesting things, and it isn't killing off anybody's favorite language.

"""How does one quantify "sinking down the drain"? """

I'm thinking along these lines: http://www.dbdebunk.com/content2006.html

"""One of the benefits of node and why its becomingly increasingly popular is that it allows ease of development with the benefits of scale built in."""

And that's --the second part-- is where they and you are wrong, as tons of teams have found out. Scale is never built in, you have to work for it.

"Scale built in" is another way of saying "Mongo is webscale".

Reply on news.ycombinator.com