[HN Gopher] On 'Function Coloring'
___________________________________________________________________
On 'Function Coloring'
Author : jeremylevy
Score : 18 points
Date : 2023-06-05 17:11 UTC (5 hours ago)
HTML web link (www.tedinski.com)
TEXT w3m dump (www.tedinski.com)
| randyrand wrote:
| > You can only await for it from an async function.
|
| get rid of this needless requirement and function coloring goes
| away.
|
| If you await, you should be able to return the raw type directly,
| without needing an async keyword.
| vore wrote:
| I think it's all a matter of how you want to draw the line: do
| you want to expose the underlying runtime to the consumer, or do
| you want to make green threads look like real threads? I'm more
| sympathetic to the latter, because real threads with kernel
| scheduling don't have function coloring and are even less
| predictable in when they yield, so why can't my language runtime
| (e.g. in Python) just pretend they're kernel threads?
|
| I give a pass to Rust for this one though, since it would need a
| more heavyweight runtime with green threads to deal with this.
| verdagon wrote:
| I often hear that if a distinction exists, it should be
| represented in the type system; functions are either async or
| not, so we should track it at compile time.
|
| The thing most people don't understand about language design is
| that if you follow this line of thinking to the extreme, your
| complexity goes through the roof as all of the infectious
| constraints spread upward through your call graph, sometimes
| conflicting with other constraints.
|
| Rust is an interesting data point. It already has at least three
| infectious mechanisms, which spread constraints upwards (async vs
| synchronous, Sync vs !Sync ("data coloring"), &mut and borrowing
| in general). If you've ever been unable to propagate these
| infectious constraints upward because you couldn't change your
| signature (because it was a public stable API, or it was a trait
| override, or it was a `drop` method) then you've felt this
| complexity first hand. I believe this is the main reason that we
| see less (healthy) abstraction in Rust compared to other
| languages.
|
| Instead, I think a language should use these kinds of
| "infectiousnesses" _very_ sparingly. In this order:
|
| * Find a solution that doesn't involve infectiousness. I think
| Loom did really well here.
|
| * Add an escape hatch (not one that stalls the entire async
| runtime, preferably). For example, interfaces are a good escape
| hatch for static types.
|
| * I very much like MrJohz's suggestion in [0]: invert a feature's
| infectiousness by changing the default color.
|
| If I had one PL-related wish, it would be for a mechanism that's
| non-infectious like Loom, but didn't involve its stack copying
| and didn't need a runtime. I have a few ideas along those lines,
| but we'll see if they pan out.
|
| [0]
| https://www.reddit.com/r/ProgrammingLanguages/comments/vofiy...
| assbuttbuttass wrote:
| > Green threads aren't easier than async functions. The function
| colors don't go away
|
| Don't they? Using green threads I can happily call a blocking
| function in a synchronous context in one place, and run it with a
| goroutine in another place.
|
| With async (particularly Rust's tokio), you need to pass around
| the "runtime" object in order to call an async function in a
| synchronous context.
___________________________________________________________________
(page generated 2023-06-05 23:03 UTC)