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

Re:Python has had async for 10 years – why isn't it more pop... by xg15 on Tuesday September 02, 2025 @05:38PM (#45109414)

I think the general idea of function colors has some merit - when done right, it's a crude way to communicate information about a function's expected runtime in a way that can be enforced by the environment: A sync function is expected to run short enough that it's not user-perceptible, whereas an async function can run for an arbitrary amount of time. In "exchange", you get tools to manage the async function while it runs. If a sync function runs too long (on the event loop) this can be detected and flagged as an error.

Maybe a useful approach for a language would be to make "colors" a first-class part of the type system and support them in generics, etc.

Or go a step further and add full-fledged time complexity tracking to the type system.

[ Parent | on HN ]

Re:Python has had async for 10 years – why isn't it more pop... by munificent on Tuesday September 02, 2025 @07:21PM (#45110384)

> Maybe a useful approach for a language would be to make "colors" a first-class part of the type system and support them in generics, etc.

Rust has been trying to do that with "keyword generics": https://blog.rust-lang.org/inside-rust/2023/02/23/keyword-ge...

[ Parent | on HN ]

Re:Python has had async for 10 years – why isn't it more pop... by lmm on Tuesday September 02, 2025 @10:30PM (#45111685)

> Maybe a useful approach for a language would be to make "colors" a first-class part of the type system and support them in generics, etc.

This is what languages with higher-kinded types do and it's glorious. In Scala you write your code in terms of a generic monad and then you can reuse it for sync or async.

[ Parent | on HN ]