Speaking of concurrent programming and parallelism. If you're not into functional programming, check out Apple's Grand Central Dispatch[1] and Objective-C Blocks[2].

Unless you write your own Objective-C http server and run it on Mac OS X Server (it's not that hard, I've done it), this isn't very useful for Web programming. However, if you're comparing the languages / frameworks themselves (you can use all three to code command line tools, for example), GCD becomes a very seductive option.

GCD works by throwing code blocks (obj-c closures) into queues, and letting the runtime do its magic. You can have it execute code synchronously, asynchronously, or in parallel.

GCD will optimize and distribute your blocks the the available CPU cores. You can even enumerate using blocks, and instead of doing loop iterations one by one, it'll distribute them to the cores in parallel.

[1]: http://en.wikipedia.org/wiki/Grand_Central_Dispatch [2]: http://developer.apple.com/library/ios/#documentation/cocoa/...

What a bunch of gobbledygook.

People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency.

Not that you'd get this from the article.

OK fine, Duncan might not have chosen the best words when comparing Node to Erlang.

But how's Node.js "backwards"?

It seems to me that the author has picked on one statement by one individual, and turned that into a link-bait.

Article is quite refreshing, given booming Node.js popularity.

This is what I thinking when reading all the discussions about Node.js (mainly here, at HN).

Disclaimer: I don't program in JS, and I won't touch it without six feet pole (read: code generator from some higher-level strongly-typed language).

My node.js project spreads all node.js i/o across multiple node processes ( in machine, network, or browser ) and creates a distributed EventEmitter across all nodes.

https://github.com/Marak/hook.io

It would be pretty simple conceptually (maybe not practically) to make node.js work in an actor-like way, here's a piece of toy code I wrote that does it for JS (not node, but no reason the same couldn't be done for node): http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap...

By "actor-like way" here I just mean a code module ("actor") sees one thread (at a time), and the runtime takes care of the details of scheduling threads when a module has an event/message/request to process. Also I guess avoiding callbacks. But you could be more Erlang-ish/Akka-ish in more details if you wanted.

node.js punts this to the app developer to instead run a herd of processes. In most cases that's probably fine, but in theory with one process and many threads, the runtime can do a better job saturating the CPU cores because it can move actors among the threads rather than waiting for the single-threaded process an actor happens to be in to become free. The practical situations where this comes up, I admit, are probably not that numerous as long as you never use blocking IO and are basically IO-bound. (Only CPU-intensive stuff would cause a problem.)

btw this has been hashed out to death on the node.js list: http://groups.google.com/group/nodejs/browse_thread/thread/c...

Does anyone know how well Scala can handle the requirements of a typical Node.js project? IE, thousands of network connections and rather light CPU load overall? Can Scala be a Node.js or Erlang replacement?

Sure, it's the reverse of goroutines, which allow you to do easy asynchronous programming using synchronous code.

Edit: looks as if Erlang does indeed have its own, separate definition for lightweight process. See the disambiguation page on http://en.wikipedia.org/wiki/Light-weight_process. How very poor of whoever started misusing an existing concurrency term to refer to something else - as if discussing these matters isn't already difficult enough.

Could someone familiar with Erlang please clarify:

"To understand why this is misleading, we need to go over some background information. Erlang popularized the concept of lightweight processes (Actors) and provides a runtime that beautifully abstracts the concurrency details away from the programmer. You can spawn as many Erlang processes as you need and focus on the code that functionally declares their communication. Behind the scenes, the VM launches enough kernel threads to match your system (usually one per CPU) "

In common Unix tools like 'ps' and 'top' the term 'Lightweight Process' is used as a synonym for OS thread, eg, the LWP column in 'ps -eLf' shows the thread ID.

In this article, LWPs seem to be different from threads? Is this correct? If they're not threads, what are they?

> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s.

Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.

I think the opinions expressed in this article are valid.

However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node's biggest problem. As others have said, it works for smaller projects (and even has some geek appeal). And as Havoc Pennington and Dave Herman have explained, generators (which are coming with ECMAScript Harmony) and promises will eventually provide a very nice solution. So Node has a path to grow out of the callback model without giving up its single threaded paradigm.

http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap...

http://blog.mozilla.com/dherman/2011/03/11/who-says-javascri...

The bigger problem (which I don't see getting solved anywhere down the road) is the lack of preemptive scheduling, which is available in Erlang or on the JVM. What you see under high load with Node is that latency is spread almost linearly over a very wide spectrum, from very fast to very slow, whereas response times on a preemptively scheduled platform are much more uniform.

http://jlouisramblings.blogspot.com/2010/12/differences-betw...

And no, this is something that can't be solved by distributing load over multiple CPU cores. This is problem really manifests itself within each core, and it is a direct consequence of Node's single threaded execution model. If anybody knows how to solve this without resorting to some kind of preemptive threading I'd be very curious to hear about it.

It seems like most people are using nodejs for the web, and nodejs includes a library for HTTP.

What are some good web libraries for Erlang?

Very well written article summarizing some discussions that are apparently common in the erlang community.

Suggesting Node and Erlang have the same concurrency model is a complete pigeonholing. CPS != Actors.

I've read a lot about Node and watched Ryan Dahl's introduction to Node and maybe the author of this post should have done that too. At no moment does Ryan talks about Erlang and having anything to do with Erlang's way of thinking. Node was built to use javascript's awesome V8 engine and its event loop that many people already know and love to provide evented IO. I love Node and I think it is a great project, which has nothing to envy about Erlang.

This is like saying "This Honda Civic clearly sucks compared to my helicopter. Let me write you an article about everything that my helicopter does betting that your Civic". Clearly the Civic was build for another purpose and so the comparison is void.

It looks to me like all this debate has no observable consequence on the respective programming communities. Node folks will program the Node way and love it and Erlang folks will program the Erlang way and love it. The creators of neither are trying to woo the other and they perfectly well understand operationally where each system stands.

> Node.js appeals to people who already know Javascript and don’t want to learn a new language

This is a blanket statement that perhaps displays the author's opinion on Javascript as a language itself.

Fair catch, I could have chosen more precise words.

Uh oh. Cue flame war.

I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.