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
More of just a hunch really. Swapping them out` was on the cards too though. And also working cleanly between different capabilities for different platforms, although that suggest I would want coeffects there, but I'm not entirely sure.
1
2