Yeah, I'm *very* aware that Promises are not truly "multi-threading" (and that it isn't possible in JS), but the way I see them used... is people trying to do something multi-threading-y. And it's... cringe. You end up with this mess of code that is hard to debug, troubleshoot, etc. (Like how MT code is too.) Something I am seeing a lot, lot, LOT in JS code I've been reading lately (don't shoot the messenger please), is people using setTimeout with like 200ms timeouts, because they are getting all sorts of random behavior due to having no guarantee of anything they expect to be instantiated actually being instantiated when they call it. Because nothing is operating in any reasonably predictable order, they know they built a screen that, at some point, will have an object with name ABC available, but they have no guarantee at any given moment that ABC is actually in existence yet (because so much stuff is running willy nilly in Promises), that code just randomly fails. And they can't (or at least, not easily/obviously) just say "hey, can you please not run this code until object ABC is instantiated", they pick a number to use in setTimeout and hope the number they picked was low enough to not delay the work from happening *much* longer than needed, but high enough to ensure that the things they are waiting on exist when they need to exist.

Can you see why in my mind, Promises are linked to multi-threading? Because these folks are writing this really nutty code, like they are trying to write MT code without semaphores, mutexes, etc., but it's all because everything is running All Callbacks All The Time and no one has any clue what context will exist when their code executes.

It's a true disaster.

For me... the real, underlying problem is that writing software is too difficult using the current tools and paradigms, for the typical developer and the typical development shop (in terms of testing code, bringing new folks into projects, etc.).

Sooooo much of this is "stuff a really smart compiler/interpreter could and should handle". Things like requests for external data (DB connections, HTTPS requests, etc.) are things that a really smart system could look at and say, "let me do this on a separate thread, and then have whatever needs that data wait for the thread to finish when it's requested"... kind of similar in spirit to a lazy evaluation in a functional language.

So what I'm getting at - I think - is that what I'm defending isn't actually blocking IO, but writing code in a blocking IO fashion, but with very, very smart systems under the hood that automagically handle the multi-threading for the developer.

J.Ja