7 ms·

It's not _quite_ the same: you can't call async code from a sync context (hence the color issue), but I can always pass a "context.Background()" or such as a co

• TheDong 3y ago
  > you can't call async code from a sync context (hence the color issue), but I can always pass a "context.Background()" or such as a context value if I don't already have one. You can always pass context.Background, in this metaphor creating a new tree of color. You can always call "runtime.block_on(async_handle)", in this metaphor also creating a new tree of color.
  • throwy2342 3y ago
    Go doesn't have async/sync distinction, no keywords so the metaphor doesn't hold.
• pkolaczk 3y ago
  You can always pass the async executor to the sync code and spawn async coroutines into it. And you can keep it in a global context as well to avoid parameters. E.g. there is `Handle::current()` for exactly this purpose in Tokio. Function coloring is just a theoretical disadvantage - people like to bring it up in discussions, but it almost never matters in practice, and it is even not universally considered a bad thing. I actually like to see in the signature if a function I'm calling into can suspend for an arbitrary amount of time.