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
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
Algebraic effects+handlers do give you interruptable sequencing, afaik (does depend on your system though).
Replying to
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
Show replies