Experimenting with Node.js

"With a callback-based system, stacks are short, and you explicitly carry that state. You KNOW what state you're storing, and you can see it easily."

Actually, no. You have implicit state carried around in the function closures and you will discover that it is very easy to have a leak in there that will be very hard to diagnose. I say this because I am speaking from experience.

(Remember, Node.js isn't a blinding new architecture. The architecture has been around for over a decade and I don't even know when the idea started. The only new aspect is that this time, it's Javascript. I've got a lot of experience with that architecture, and what that experience tells me is never again!)

On the other hand, it is very easy to examine an entire running Erlang system, see every process and the exact contents of its stack at that point in time, and the exact amount of memory currently allocated to it, and since Erlang doesn't have any sharing between processes, that state is everything about that process. It isn't always the best about giving back memory if you have long running processes, but I was able to diagnose which processes were consuming my RAM, determine why they were consuming my RAM, and test out a fix for the excessive RAM consumption (since it came in the form of sending a particular message sooner rather than later), all without shutting down my server.

You do not have that level of introspection and visibility in Node.js. I don't even have to ask.

"Many languages and many runtimes allocate stacks in megabytes, and store every local variable in it."

I'm not talking about "many languages". I don't care about "many languages". I'm talking about good languages. Erlang can very easily allocate a couple hundred bytes to a process, or less. I'm not actually sure what the minimum allocation is, but it is certainly going to be competitive with a minimal Node.js handler.

"Receive a starting event, emit a done event -- you aggregate processes into sets of events, not into function calls. So yeah, it's not going to follow some of the same patterns that non-event-driven code follows, and event-driven code is going to look rather different than callback-passing code."

None of that appears to have any relationship to coding in Erlang, from what I can see. Better technologies don't have to have events. They just code right through things. A loop for a simple proxy might look like:

    proxy(SenderSocket, DestSocket) ->
        case socket_read(Sender) of
            done -> done; %% return to the original caller
            {ok, Data} ->
                socket_write(DestSocket, Data),
                %% go back for more
                proxy(SenderSocket, DestSocket);
            {error, Error} ->
                handle_error(Error)
        end
    end.

    spawn(fun () -> proxy(SomeSender, SomeDest))

Erlang doesn't actually use coroutines, Haskell does only upon request, coroutines for concurrency are just cooperative multitasking and I mock them as well, albeit for different reason.

You need to try Erlang. If only to know how to argue against it without arguing against some fictional language that doesn't exist.

the blinky body toggle was pretty cool to see though :)

Just for sake of completeness, you can basically copy-paste that code into Ruby as well via em-websocket: http://github.com/igrigorik/em-websocket

Also, to avoid some of the callback muck that a few have brought up: http://github.com/igrigorik/em-synchrony

(same idea, closures + coroutines to abstract the callbacks).

I feel OK about doing this.