←back to thread

Python has had async for 10 years – why isn't it more popular?

(tonybaloney.github.io)
320 points willm | 2 comments | 02 Sep 25 17:24 UTC | HN request time: 0.4s | source
Show context
baq ◴[02 Sep 25 17:36 UTC] No.45106384[source]▶
async, parallelism, concurrency, why not all three? JS, the canonical async (at least today) language, has had neither parallelism nor concurrency primitives for a good decade or so after its inception.

I personally blame low async adoption in Python on 1) general reduction in its popularity vs Typescript+node, which is driven by the desire to have a single stack on the frontend and backend, not by bad or good async implementations in Python (see also: Rails, once the poster child of the Web, now nearly forgotten) 2) lack of good async stdlib. parallelism and concurrency are distant thirds.

replies(1): >>45106668 #
dragonwriter ◴[02 Sep 25 17:55 UTC] No.45106668[source]▶
> async, parallelism, concurrency, why not all three?

async is a concurrency mechanism.

replies(1): >>45106722 #
1. JackSlateur ◴[02 Sep 25 17:59 UTC] No.45106722[source]▶
async enables a concurrency potential, nothing more

That is, if you use external stuff and can delegate work to them, then async is concurrent (async io for instance)

But if you do not, then async is regular code with extra steps

replies(1): >>45108628 #
2. DanielHB ◴[02 Sep 25 20:32 UTC] No.45108628[source]▶
I do not understand what you mean, parallelism is running multiple concurrent execution blocks running in multiple physical CPUs at the same time.

My understanding is that JS can't do that (besides service workers which are non-shared memory), but it still has multiple concurrent code-blocks being executed at the same time, just in linear fashion. It will just never use multiple CPU cores at the same time (unless calling some non-JS non-shared-memory code)