On 'function coloring' (2018)
tedinski.com
On 'function coloring' (2018)
1–10 of 22 posts
Re: On 'function coloring' (2018)
#2> 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.
Re: On 'function coloring' (2018)
#3I 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.
Re: On 'function coloring' (2018)
#4I 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...
Re: On 'function coloring' (2018)
#5> 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.
Re: On 'function coloring' (2018)
#6> The less interesting version is that you do always have to option to just block. You can call a task runner on that future, and synchronously block until that specific future completes itself. This isn’t the greatest approach, because we probably don’t want to block, but it is an option.
My first thought, coming from a JS perspective, was “no, you actually can’t do that”, because blocking the event loop will prevent resolution of the Promise. My next thought was that this is particular to a single threaded, cooperative concurrency model, so of course “can’t” is situational.
But on further thought, it’s much closer to my first thought: you can do that if you can interleave asynchronous ticks with synchronous ones, but only if you can determine there are no data races (or accept them if there are). This is something I suspect Haskell (or Rust?) is probably well suited for, but for JS it’s a complete non-starter.
Another comment made the point that the async keyword (the explicit “color”) is at issue, and I nearly made this comment there because it raised the same concerns for me from a different angle: if you can “await” from an otherwise synchronous function, you’re either accepting data races, blocking permanently, or implicitly “coloring” all functions as async with the same implication that you can statically eliminate races.
At which point, writing this, I realized this would all be so much simpler if everything was a statically analyzable DAG with transactional semantics.
Re: On 'function coloring' (2018)
#7> The less interesting version is that you do always have to option to just block. You can call a task runner on that future, and synchronously block until that specific future completes itself. This isn’t the greatest approach, because we probably don’t want to block, but it is an option. My first thought, coming from a JS perspective, was “no, you actually can’t do that”, because blocking the event loop will preven…
In Rust, blocking the current thread on future completion is spelled `block_on(your_future)`. https://docs.rs/futures/latest/futures/executor/fn.block_on....
Re: On 'function coloring' (2018)
#8> The less interesting version is that you do always have to option to just block. You can call a task runner on that future, and synchronously block until that specific future completes itself. This isn’t the greatest approach, because we probably don’t want to block, but it is an option. My first thought, coming from a JS perspective, was “no, you actually can’t do that”, because blocking the event loop will preven…
In Rust, blocking the current thread on future completion is spelled `block_on(your_future)`. https://docs.rs/futures/latest/futures/executor/fn.block_on....
Looks like it satisfies the cooperative interleaving via LocalPool. I’m not surprised there’s a built in solution, I’d expect (safe) Rust to have all the information it needs about pertinent dependencies to make cooperative polling feasible and safe. I am a bit surprised it sounds ergonomically exactly like what JS devs might naively assume they could do (I guess what I mean is… I was expecting a little more ceremony?).
Re: On 'function coloring' (2018)
#9It would be nice to mention in the Haskell part the solution which is just use 'trace', which just prints the thing and also evaluates to it, so it's just a pair of parens and a keyword and away you go.
Re: On 'function coloring' (2018)
#10Related:
What color is your function? (2015) - https://news.ycombinator.com/item?id=28657358 - Sept 2021 (58 comments)
What Color Is Your Function? (2015) - https://news.ycombinator.com/item?id=23218782 - May 2020 (85 comments)
What Color is Your Function? (2015) - https://news.ycombinator.com/item?id=16732948 - April 2018 (45 comments)
What Color Is Your Function? - https://news.ycombinator.com/item?id=8984648 - Feb 2015 (143 comments)
What Color Is Your Function? - https://news.ycombinator.com/item?id=8982494 - Feb 2015 (3 comments)