So @Kyrenite was showing me a cool new idea she had with GC in Rust and we had a pretty neat realization about this space
Conversation
Her idea was that a GC in Rust can use a futures-like API, and the space between polls is where gc pauses can happen. It didn't use async yet but it could do something like that in the future.
see github.com/kyren/luster/b
(the overall gc design here is very cool, check it out)
2
5
31
I pointed out that this is actually quite similar to what Go does: Go generates automatic GC interruption points, and the same mechanism powers async I/O scheduling
4
1
17
Is this because you can kind of think of GC - or any dynamic allocation - as an effect? I'm imagining a GC-less language with algebraic effects and handlers might form another alternate foundation here (see how Multicore OCaml uses effect handlers for async scheduling).
1
1
Yes, looking at GC-ish functions as having a different "color" helps.
But effects are more general, this has to do with GC being something that needs to interrupt execution to change things.
Like a green threading scheduler.
1
1
GC is your code running (lightweight) concurrently with a collector "thread"
1
Replying to
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?
Algebraic effects+handlers do give you interruptable sequencing, afaik (does depend on your system though).
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
Show replies