Node.js vs Erlang: SyncPad's Experience(blog.mysyncpad.com)
blog.mysyncpad.com
Node.js vs Erlang: SyncPad's Experience
http://blog.mysyncpad.com/post/2073441622/node-js-vs-erlang-syncpads-experience
6 comments
It would be really useful for him to say what Node.js version he's using. Node <=0.2.3 has a bug related to reaching the file descriptor limit of the OS that makes CPU usage go through the roof, for example.
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.)
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.)
Yes! This! Let's be reasonable adults about this: node.js and V8 are very new projects that are really impressive given their age. OTP is an incredibly mature and proven platform.
EDIT: If you're interested to really see what node.js's main issues are, check out Ryan Dahl's (node.js creator) presentation at JSConf.eu 2010. http://jsconf.eu/2010/speaker/techniques_for_a_single_stack....
EDIT (2): Yes, meant OTP, not OLTP. :)
EDIT: If you're interested to really see what node.js's main issues are, check out Ryan Dahl's (node.js creator) presentation at JSConf.eu 2010. http://jsconf.eu/2010/speaker/techniques_for_a_single_stack....
EDIT (2): Yes, meant OTP, not OLTP. :)
Minor pedantry note: I think you mean OTP (http://en.wikipedia.org/wiki/Open_Telecom_Platform), rather than OLTP (http://en.wikipedia.org/wiki/OLTP).
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'll run the test again later tonight and post a follow up.
A follow up would be great. 0.2.3 apparently had a file descriptor bug which could be the cause of this.
http://twitter.com/#!/ryah/status/10748819335553024
http://twitter.com/#!/ryah/status/10748819335553024
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...
Why does JSON have to be involved at all? A binary format using UDP packets would perform much better.
I was trying to use SyncPad with my dad last night to try out as a means of doing Hangul lessons over the net, and performance was usable but uncomfortably laggy.
I was trying to use SyncPad with my dad last night to try out as a means of doing Hangul lessons over the net, and performance was usable but uncomfortably laggy.
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)
Why not combine both?
Use Erlang/OTP for writing telecom-grade servers and Javascript for embeddeded scripting engine. Both Riak and CouchDB do exactly this.
Use erlang_js OTP application:
{erlang_js,"Interface between BEAM and JS","0.4.1"}
{erlang_js,"Interface between BEAM and JS","0.4.1"}
The page is now showing "We'll be back shortly. Our servers are over capacity". Now I'm really interested in which one they are currently using.
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.
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 :/
Interesting... Just a heads up if anyone cares: We had at least one tumblr submission yesterday, too, that had trouble. Two days in a row might be a larger red flag for tumblr or tumblr users.
> Two days in a row might be a larger red flag for tumblr or tumblr users.
Twitter has been having this sort of problem since always. Users don't seem to care about a little downtime.
Twitter has been having this sort of problem since always. Users don't seem to care about a little downtime.
Hacker News itself has hiccoughs, too, but here we are.
back up
It's not because Node.js is a new thing. It just that JavaScript is a client language, why would use it on a server anyway? Use the appropriate language for your projects and in this case it's Erlang.
EDIT: For all those Node.js zealots, thanks for downvoting.
EDIT: For all those Node.js zealots, thanks for downvoting.
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.
No, JavaScript is a language, it's been used on clients and servers for quite a few years now.
...and it's quite clear that using it on the server is not that efficient compared to other languages that were designed to run on the server. The article proves that point.
I'm afraid you've confused a language with a particular virtual machine that runs it. That's like criticizing CSS because Internet Explorer implements it badly. The article proves nothing other than one particular JavaScript VM isn't as efficient as Erlang, not exactly a big surprise considering that's not what the VM was written for.
the language has very little to do with efficiency or suitability for server / client side.
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.
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.
I think that he meant to say that V8 wasn't designed for long running processes like servers. In the browser it starts up, executes some code and then shuts down. Keep state around for a long time tends to lead to issues that take time to find / fix.
It has absolutely nothing to do with the language.
Oh but it is otherwise people would be using JS to move robots.