Node.js vs Erlang: SyncPad's Experience (opens in new tab)

JavaScript isn't a "client" language - it's a language designed to be embedded in a host system, which is exactly how Node.js uses it. Server-side JavaScript has been around since Netscape Application Server back in the late 90s.

> It just that JavaScript is a client language

No, JavaScript is a language, it's been used on clients and servers for quite a few years now.

There's no such thing as "client" or "server" languages.

Turing-complete languages like Javascript can be used for any purpose, regardless of its most common application.

Someone has even written a webserver in PostScript: http://www.pugo.org:8080/

Javascript is particularly well suited to evented style programming because it has a very simple support of first class functions.

It has absolutely nothing to do with the language.

To be honest, though, this is the result you really should expect. Node.js is a relatively new thing that is a bit of a clever hack on top of a language runtime that is powerful but was not directly designed for this usecase, running a language that is also powerful but not directly designed for this use case. Erlang is a language that has been open source for 12 years (and was actually started in 1986), both the language and the runtime are specifically designed for this use case and has had years of tuning and bugfixes, and this problem is right smack dab in the middle of what Erlang targets.

This isn't a criticism of Node.js... it's just the way it is. Every language was young sometime.

(It will be interesting to see if Node.js ever quite catches up, though; when you've really pushed the performance to the max for a given design decision, you get down to the point where you can't improve without changing those decisions. Erlang's GC, for instance, is absolutely written around having a lot of threads that may be running on different CPUs, which adds a lot of complexity that the V8 project, or any JS runtime project in general, may be loathe to introduce into what is still fundamentally something that should be able to go into a browser. But that's for the future to resolve.)

When I wrote the Node.js server in September, the latest version was v0.2.3; which is what I tested on. I failed to mention that in the post, but thanks for pointing that out.

I'll run the test again later tonight and post a follow up.

I had to restart my node servers almost on a daily basis because of this bug. Was about ready to jump on Erlang myself ironically (building a stream server with mochiweb). Glad I read this and will give Node.js some more time to mature.

I just glanced at his traces, and it appears GC is taking on the order of seconds near the end. Since he had only 1 client, I'm guessing it's more a problem with garbage collection than with file descriptors. Of course, only a test with the newer version of Node will tell...

Random thought:

Many company and developer blogs? Hosted on completely different technology from their main web sites. Maybe not even hosted on their servers, but instead with a service - like this one.

Maybe we can avoid the increasingly stale snark about <web technology mentioned in blog post> not working so well when a blog post goes down under heavy load.

Doubly so when it's a freakin' iPad app, not a web-app being talked about.

tumblr :/

back up

It sounds like he tried to figure out how to process binary data with Node.js using "Buffers" but didn't get it working before switching to Erlang.

contact me @roder to talk about the performance. There was a bug in 1.0 on the iPad app that didn't keep the line up with your finger. Now in 1.0.1, which is in the queue for approval, that has been resolved. Hopefully the network stuff was ~ok~

SyncPad 1.0.1 is approved, see if that fixed your problem (I suppose your lag was local)