Node is single-threaded + async-everything which gives you simple concurrency with the async/await abstraction. It's these there things that come together to make building async apps simple. For example, I went out of my way to avoid Node before it had promises and async/await, and that seems to be the Javascript most HN users remember.

Concurrency in this situation almost becomes free at the expense of changing

    user = db.findUser(42)

to

    user = await db.findUser(42)

So when writing programs where you want more than one I/O thing to be happening at a time whether it's network requests or a bunch of concurrent workers, which is pretty much why you'd use Node, you get it trivially.

Even something like running parallel DB queries trivially inside an Express route:

    const [a, b] = Promise.all([db.findUser(42), db.somethingElse()])

Or starting one async early, waiting on another, and then ensuring that the first async thing is done later on:

    const a = runA() // returns a promise
    const b = await runB()
    return [a, await b]

And once again I think this is the a great example of a useful abstraction when writing anything with an I/O boundary:

    const results = await all(urls, url => crawler(url), { concurrency: 8 })

That code in Go would take me 40 lines and involve wait groups.

Compare that to Netty or trying to write async code in Rust where it's really easy to block the event loop because all libraries and stdlib are sync by default. So you're passing around a CPU pool to run sync code inside your async context. It's hard to look at that sort of code and understand its runtime behavior. Oops, you accidentally blocked. Oops, the pool gets saturated immediately and starts blocking. It's hard to straddle both worlds, and the code is constantly trying to "return to its sync default" so you have to be eternally vigilant. Sync isn't necessarily the default you want, either.

Of course, this comes with other expenses like needing to run one process per core and you can't do CPU-bound work in-process. But you may be used to that limitation using Ruby or Python for example.

I'm not trying to start a language war or tell you that you should drop what you're doing to use Node because it's The Best.

What I'm responding to is this idea that you couldn't possibly have a technical reason to use Node given a choice unless you're fresh out of a boot camp and know no better.