Anyway, in our case we (1) like the async programming model, and actively use it -- on the server side, our services tend to be modular and actually speak over RPC layers to each other, not just one big ugly web process. Node is great at this.
And (2) in this case, because we wanted to have a lot of shared code among our first implementation of a client, our browser front end, and our server. It worked very well to work on all three with one language. It's worked out.
I personally miss compiling C++. :-)
There's a very good chance we'll end up writing a Go client for Keybase. We might switch the official reference client once the functionality is more locked down.
Lastly: it's really CoffeeScript, not JavaScript. Which is a different can of worms to open on here.
I've used zsh as my interactive shell for years, but I always still write bash scripts instead of zsh scripts. You can count on bash scripts running just about anywhere.
"Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?"
and was agreeing with the first part of the sentence and then laughed out loud at the end ...
Are we really in a world where ruby is the old school traditionalist way to write unix utilities ?
EDIT: also wanted to add that node exposes your standard POSIX-style interfaces to the OS, so there's really no reason it can't be a general purpose replacement for other languages for writing system tools.
Perl/Python come installed by default in the majority of distros (and Mac OSX)
They're also more mature at this stage
So, yeah, node may one day be as supported as them, but today it is at a disadvantage.