[brundolf]

And the performance argument isn't even just about CPU time, right? The fact that JS is heavily event-friendly, and all of its IO APIs are non-blocking by default, gives it an automatic advantage over busy-waiting languages like Python, and also languages where concurrency means writing threads manually. If your web server spends most of its time on IO (network, DB, file system), as many do, JS acts as a lightweight task-delegator to a highly parallel and performant native runtime.

I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make

[nl]

You have to work pretty hard to make Python (or any other language with reasonable web frameworks) busy-wait!

Blocking is NOT the same as busy wait.

[brundolf]

Ah, I didn't realize there was a distinction

Still, despite that it seems like there's a big advantage to be had

[nl]

Is there thought?

What's the actual difference between (JS):

  let x = await doSomeLongProcess();
  console.log("done: " + x);

vs (Python)

  x = await do_some_long_process()
  print("done: " + x)

[brundolf]

Sure, if you use Python's async feature. But my understanding is that it's relatively uncommon; blocking IO is still the norm, right? I for one have worked in or around a couple of nontrivial Python servers, and I've never once seen an await statement. My understanding (correct me if I'm wrong) is that this comes down to it being newer, and having worse ecosystem support (more "synchronous-colored" APIs, less battle-tested frameworks, etc). It's not a first-class citizen like it is in the JS ecosystem [1]

[1] Technically JavaScript's async/await syntax came later, but it's just sugar over Promises which have been around for a much longer time, and those are built atop the event loop, which has been core to the language since day 1

[yencabulator]

In non-async Python, generally the thing that blocks is a thread -- something Javascript doesn't even have! A different thread will happily run in the meanwhile.

[brundolf]

Right, but some other JavaScript on the same thread will run while a different piece of JavaScript is awaiting. That's why JavaScript can get away with not having threads. Also- any number of background threads will be running at any given time to read data off of disk, load and process network requests, load data from a DB, delegate commands to system processes, etc, in true parallel with the JS code. When one finishes, it'll put an event on the event loop and JS will pick it up when it gets the chance.