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.

> 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...

> 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.