I agree. It's interesting to see node fans get huffy when Erlang people say, "hey, we're still #1"

But for people who already love JS, node is a dream come true. It's really fast. Not as fast as Erlang, but more than fast enough to justify building massive projects in it. Assuming you are one of those that loves, or believes in, JavaScript...

Don't you find using callbacks for everything to be a straightjacket?

Personally, yes. I like to use eventlet in Python partially because of that. Interacting with the scheduler is implicit in eventlet (and gevent, which some prefer) so you write code that looks synchronous.

On top of that, you get nonblocking I/O almost for free, similar to what node attempts to provide, where instead of real nonblocking I/O the system will make blocking I/O look like it's nonblocking. Scala does this too.

But, users of Twisted could also use inLineCallbacks for a similar feel, though it's not required. I'm curious if Node.js could just build the same?

There are some nice libraries that ease the pain of callbacks to a certain degree.

Async[1] (the waterfall method) and Step[2] come to mind.

[1]: https://github.com/caolan/async

[2]: https://github.com/creationix/step

This pretty much spoils the whole idea that you'll use your clientside JS on the server though, huh?

The callback issue means that client and server are really not running the same language. They sorta look the same I guess.

I'm not sure about step, but caolan's async is perfectly usable in the browser, as well as in node.

That said, code sharing between browser and server often extends to templating, validation and a few utilities, in my experience. More complex logic is better served with message passing or something like dnode.

Erlang was not designed with performance in mind. It's only gotten reasonably performant in it's later life.

That's not quite fair. Erlang was designed from the start to be very, very fast at process switching and message passing. True, that design took a while to bear fruit, but my understanding (from listening to Joe Armstrong speak about it) is that being able to make the core of the language highly efficient was a goal from the start.

Trying to make it as efficient as possible is different from the purpose of the language being efficiency.

Indeed, but in this case both apply.

EDIT: Give this a listen, the early design and development is described in more detail than I'm capable of going into: http://www.se-radio.net/2008/03/episode-89-joe-armstrong-on-...

Indeed. I'd really like to see the Haskell servers, warp and snap, thrown in, since the infrastructure there was actually built for raw performance.

I have put together the code to implement the benchmark using Snap and would be happy to share with anyone willing to boot up the instance and run.

I might do so myself if I find the time tomorrow.