Single-threaded isn't a benefit, but in a world where multi-process isn't a problem, a lot of that is blunted. Granted, for problems that are both compute- and IO-heavy, something like the JVM makes much more sense (so just use it--duh, right?). For throwing bytes over a wire, something like Node is really, really easy and really, really effective. My biggest beef with it is the weak libraries for talking to RDBMSes, that's about it; my API tools of choice remain Ruby/Grape/Grape-Swagger because ROM is so much nicer than anything I've seen in Node, but that's really about it.

Like I said upthread, I used to dunk on JavaScript a lot, but it doesn't make sense nearly as much as it used to, to me.

    >Single-threaded isn't a benefit

Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you don't deal with the certain pitfalls of multi-threadedness.

Seriously, use Erlang or Elixir and have both concurrency and ease of programming and debugging relative to Node.js. Spoken as someone who has created multiple Erlang projects with close to zero unintended downtime for months or years in production.

I like what I've seen of Elixir. (As a Rubyist by habit, I should.) But it doesn't do what Node does:

Use JavaScript.

We can say 'til we're blue in the face that that doesn't matter (and I do, as a Ruby/Grape guy for APIs), that matters. Lowered impedance mismatch is a thing. I use Ruby because I'm still more productive there--but that's a library problem (RDBMSes), not a language problem.

Node really is good-enough. I'd go for either a JVM or a BEAM-based solution if I was building things where there were significant and meaningful losses on the table if I fucked up, but for most things? Nah. Just...not important enough.

If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie.

We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.

The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner.

Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not.

(Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?)

I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)

Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?

I used to love to idea of a global interpretator and/or a single thread (coding without concurrency). It was great until it wasn't. Learning Elixir helped me get over that.

The thing is : it isn't an "idea" at all. These projects ended up with a big lock, or not tolerating reentrancy due to history -- they were developed at a time, and in an environment where there were no threads (or where support for threads wasn't of interest to the developer). It's just a bug. Not an idea, not a benefit. All the talk of it being the best way is nonsense invented after the fact to try to justify something that's just broken.

I'm an Erlang practitioner since 2007 and I approve this message ;)

Learn Elixir or Erlang and show that there's an alternative to Node.js that's both fun and powerful - and battle tested.

Ya, my next green field project will definitely use something actor or CSP flavored. Maybe clojure based, more likely Elixir or equiv.