Nodejitsu (Hosted Node.js platform) Raises $750K from East/West Coast VCs | Hacker News Reader

Nodejitsu (Hosted Node.js platform) Raises $750K from East/West Coast VCs

betabeat.com

18 pointsfrankdenbow23 comments

"I/O has been done wrong for the last 30 years,” he said, referring to the fact that Node.js allows servers to react to specific events."

This statement shows how hype-oriented this team is. Node.js hasn't invented anything new. On top of that, it reimplemented 30 year old concepts badly.

I don't want to start a language war, but a simple comparison of Erlang (which is 20 years old) and Node.js will send this point home:

1) http://stackoverflow.com/questions/3887433/advantages-of-erl...

2) http://journal.dedasys.com/2010/04/29/erlang-vs-node-js

I think Node.js is neat but could someone tell me how it's so awesome.

When Rails came it was truly awesome because the language it used and the framework was so much easier to work with then Java or .Net and some would say better designed then Perl or PHP.

I don't see how Node.js makes developing so much easier than say Rails (unless of course you have a crazy high IO kind of app, which most don't)

Node.js isn't easier than Rails, at least for the things that Rails is good at. Node.js is good for apps that require high I/O concurrency, things like chat servers, but much much worse than Rails for pretty much everything else. I see Node.js only being useful for special types of applications, it is not the next Rails or anything like that. Unfortunately I foresee that people will (ab?)use Node.js as some kind of Rails replacement.

Thanks for the insight

To add to what FooBarWidget said, I do believe that there are inherent advantages to using JavaScript on the server for developing webapps. For one, due to the dominance of JavaScript within browsers, it is the one dynamic language we will be stuck with for at least the next 20 years!

However, unless you're implementing servers, I believe it's better to go with synchronous I/O to simplify webapp development. That is exactly what we're doing at Akshell (http://www.akshell.com).

Why do you believe synchronous I/O is better for building web apps? Certainly it is worse for utilizing resources. The problem seems to be that most of the internet is about 20 years behind when it comes to performing I/O well. Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built.

Because most webapps do not need to be optimized for performance, but rather for ease of maintenance.

Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives.

At Akshell we're adding a Node based pubsub server with support for both server and browser based subscribers, allowing us to get the best of both worlds: a large number of concurrent connections combined with business logic & message processing using synchronous code.

> Because most webapps do not need to be optimized for performance, but rather for ease of maintenance.

I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node.

> Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives.

This is exactly how you write an Erlang application. Erlang supports asynchronous I/O.

Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).

Agreed on the first part, unfortunately most functional languages are difficult for most developers (read: non-academics or HN readers) to grasp. As somebody who taught me ML said: "if it's difficult to write, it should be difficult to read". Perhaps this will change, but it will be a while before we have a functional language that's as mainstream as JavaScript.

Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...

Brings me back to my original comment:

> Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built.

Someday....someday...

Don't compare Erlang to Node.js. Erlang is not a good implementation of evented servers. I'm not saying that Erlang is a bad implementation of evented servers, I'm saying that Erlang doesn't implement the evented architecture at all. Instead Erlang with its lightweight processes is more similar to the plain old 1-thread-per-IO-channel worker model except Erlang can spawn many more processes than the OS can spawn OS threads. Not that there's anything wrong with this; Erlang's processes are so lightweight that you can essentially get the same amount of scalability as evented servers.

The advantage of Node.js over Erlang is that it makes scalable I/O available in a mainstream high-level language. I do not call Erlang mainstream. Although I do think Node.js is a bit overhyped; Ruby's EventMachine and Python's Twisted provide similar functionality, and in particular EventMachine is extremely well-written.

I disagree with you. Determining how well they solve the problem they claim to solve relative to each other is a valid comparison.

Why in the world would you compare these two? It's apples to oranges...

How? They are both trying to solve the same problem and they take different approaches, what is unreasonable about comparing that?

And what problem is that exactly? Just please don't say concurrency and/or scalability, because it's huge generalization.

Erlang is language for building massively distributed applications, which is achieved via message passing.

Node.js is event-driven framework build on top of V8 JavaScript engine. It doesn't scale outside of single machine.

I can't imagine a project, for which both: Erlang and Node.js could be considered as right tools for the same job.

> Node.js is event-driven framework build on top of V8 JavaScript engine. It doesn't scale outside of single machine.

The fact that it's built on top of the V8 JavaScript engine says nothing about anything. And the statement "it doesnt' scale outside of a single machine" is just patently false. It has support for sockets, which gives it immediately the ability to scale outside of a single machine.

How do you think remote processes are communicated with/and or spawned in beam (Erlang is built on top of a virtual machine too! imagine that)?

Uh, huh--sockets.

They are both providing a model for performing concurrent work. Erlang is quite good at writing distributed applications, but not everyone is writing distributed applications. WebMachine and Mochi both address a similar set of problems someone would want to address with Node. To argue that the problems people want to solve in Erlang and Node do not overlap is amazingly unimaginative.

Yes, but now you're comparing WebMachine and Mochi to Node, which is fine...

So you can imagine a project for which Node and Erlang are valid solutions?

I see your argument for language vs framework, I just don't think it matters. Erlang already has a concurrency solution, and it's baked into the language. NodeJS is a solution to concurrency for a language that doesn't have one. I see comparing the two as valid because the question we are discussing how to solve the problem of performing concurrent work.

OK, let me put this differently.

Why do people use Node.js? Because it solves concurrency issues or because it's easy to use JavaScript application server?

Why do people use Erlang? Because it solves concurrency issues or because it's massively distributed and fault-tolerant system?

Just look at the popular projects and communities behind those two projects :)

Don't get me wrong, I agree that both solve concurrency issues, but this is just tiny part on which they overlap and I don't believe that they are meant to solve the same problems.

This looks like a very popular new business model for the startups. Take any existing or upcoming langugage/framework like php, RoR, django, node.js etc. etc. and start creating a dedicated hosted platform for that a la Heroku. And start counting the money flowing in.

Just doing a "git commit; git push; cap deploy" on your own app and feeling confident in the outcome is not an insignificant amount of work. I can't imagine what it would be like to take an upcoming environment and create a platform around it to let anyone deploy, run and be backed-up without thinking.

So, if you can pull this off and make it look easy, then take my money.

With the permanent stream of Node related stuff I have to ask is this what hacker news was like a few years ago with Rails?

(I am aware node and rails are not direct substitutes)

Reply on news.ycombinator.com