Ah. I was coming at this from the perspective of "why would it be implemented this way in JavaScript specifically", as you'd asked about JS land.
More generally, I don't have a good enough overview of programming language trends to speak to how that fits in with other languages' approaches to async.
> Is it common these days to mix promises and threads
I'm not sure. That probably depends a lot on the evolutionary history of a given language and its library ecosystem.
I could see it being done to mix those two things in a world where you are trying to glue together two libraries (or legacy internal modules) built in different ways, and the alternatives either don't exist or are more onerous.
And I think the example is a good one for how doing parallell io can be simple with async tasks/promises:
require "async"
require "open-uri"
Async do |task|
task.async do
URI.open("https://httpbin.org/delay/1.6")
end
task.async do
URI.open("https://httpbin.org/delay/1.6")
end
end
(completes in ~time of slowest request, not sum of requests).
Sure, one could use threads/processes/green threads etc.
However what languages are you thinking of when talking about this?
I've done a lot of Java programming where we commonly use threads and thread pools, although there are non blocking libraries out there too.
Is it common these days to mix promises and threads (waiting on a promise in a thread), or is what I just said nonsense?