Conversation

Yeah, I was kind of wondering if it is like how people learn that single element lists and map/flatMap are handy for expressing nullability in languages without an Option type. Do futures give me more 'structure' than I want for GC?
1
Yeah. Bear in mind, the problem being solved here is "rust doesn't like GC bc it pulls the rug out under it" and async as a solution is good because it is language support for pulling the rug out from under things
1
1
Whether or not it's too much structure depends on what you're using GC for imo. Though "too much" is fuzzy bc the alternatives aren't necessarily great.
1
I think it may work for servo (perf willing) because servo splits out most of its logic out of the dom, and the dom mostly wraps things and does tree manips. It's still *complicated*, but not pervasive.
1
Yeah, this is very much a "this improves rust" thing, if you're able to add first class language level support there are easier routes to go (Though as Graydon mentioned runtimes often internally treat async and GC interruption points similarly)
1
1
Yeah, I've been considering adding algebraic effects to my hobby language, and was considering using effects for allocators. This gives me more encouragement, so thanks for sharing! (It's not all roses though - I want zero-overhead handlers somehow, which is kinda tricky)
1
1
ooh- before this what was the motivation for using effects for allocators? ability to swap them out, or is there something else?
1
1
Tricky thing as always is the integration between this, dependent types, and my hopes for zero-cost stuff. I might just try to rule out 'dependent effects' for now, but those might turn out to be useful. Hoping some academics come out with some interesting new work to help me!