Ocaml has no concurrency options worth mentioning (need to look to PolyML/SML or F# for that). Finding and teaching Haskell devs simply isn't feasible. C++ is way too low-level for most of the work that someone choosing node would be doing.

It turns out that most of the reasons a server needs threads is IO. With node, any IO is moved to a new thread, so you get most of the threading benefits, but are completely safe (provided libuv is safe).

Another consideration is JS being dynamic. It's very easy to create extremely flexible APIs and you can move very fast adding features without breaking things. While That SML or F# app will provide much better type guarantees (and somewhat better performance), those benefits simply don't pay off for a lot of projects.

There's also something to be said for functional vs OOP styles. You will never see a JS dev writing enterprise fizzbuzz. Even in very large projects, those layers of boilerplate abstraction simply won't exist. Part of that is being dynamic and part is being functional.

> Ocaml has no concurrency options worth mentioning

LWT is a thing.

As for being dynamic, my experience has shown that beyond prototyping, most dynamic languages don't scale with the teams.

You apparently never seen enterprise JavaScript, specially in projects with multiple consultancy companies being part of the mix.

> With node, any IO is moved to a new thread

Not quite (or somewhat): the IO is done asynchronously. You tell the kernel to notify you when any of a set of FDs are ready for reading/writing, and it resumes you when that is so.

My understanding is that libuv creates a threadpool that it uses for IO operations and these inform the main thread when an IO event is ready. Is there something wrong with my understanding?

You're both right, although you more than the other guy being a dick. libuv uses a thread pool for asynchronous I/O for everything but network requests, which are handled on the main thread - presumably because they're already asynchronous by nature.

http://docs.libuv.org/en/v1.x/design.html

Yes there is something wrong with your understanding.

I recommend reading epoll(1) or kqueue(1).

It's a combination of both.

The event loop and non-blocking I/O are inherent in JavaScript. The language lends itself very well to scalable server-side programming.

How are event loop and non-blocking I/O inherent in JavaScript?

There are plenty of event loop and non-blocking I/O libraries for the languages I have mentioned.

Yep, that's true. However, JavaScript does it right out of the box and the JavaScript ecosystem is very well-aligned for async.

One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.