@ServoDev at Mozilla Research. @rustlang team; orga @rustconf. 
Open Source. Likes languages. Repatriate. Formerly physics. he/him तो/त्या- il/lui 他
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
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
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 https://github.com/kyren/luster/blob/3e3a6ea12f6f523c105abd7fbe9d0ad226be784c/src/sequence.rs#L5-L36 … (the overall gc design here is very cool, check it out)
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
Whereas, Rust is getting futures/async/await/pin/etc. These provide safe, ergonomic, sequential-looking interruptible code for async I/O (and other things), which you can use (abuse?) to get GC interruption points!!
our realization: the main problem with GC in rust is that it's hard to have safe code when random mutations may run code that steals your lunch async/await/pin are *explicitly* designed for making such interruptions safe and ergonomic to work with! they're almost the same!
even without using it all, you can get major wins from the async/await stuff
@withoutboats has a GC design that uses Pin to get soundnesshttps://boats.gitlab.io/blog/post/shifgrethor-i/ …
@Kyrenite's design uses something like futures, and might benefit from something like async/await when generators stabilize (for reasons specific to her gc, it can't use stdlib futures and thus can't use async/await directly)
I brought this up with @asajeffrey and @lastontheboat and there's some cool stuff we could do in servo's javascript GC design using both async/await and pin together
(we may be able to get away with using stock futures and async/await)
in servo's case it means every function that may trigger GC becomes async, and pin can be used to avoid holding on to unrooted values cross-interruption async gets us just about enough explicitness about interruption to satisfy rustc, without being so wordy that it's annoying
I'm curious why there are attempts to get GC in Rust. What are the use cases?
https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/#motivation … hasn't really changed since then
basically: - some graphy datastructures are nicer with gc - if you're writing or working with a managed language runtime, you need to deal with gc'd objects
servo integrates with spidermonkey and has to throw around managed DOM objects Catherine is writing a Lua runtime.
there's not so much need for *pervasive* GC in rust, but having a Gc<T> type has a lot of use cases
JITGC GC as a Service
Having a Erlang-style thread-local GC in Rust would be _so nice_ and binding GC safepoints to async waits would be cool as we can (I think?) assume that people generate limited garbage between those in concurrent Rust. I think this is a great idea! Thanks for sharing!
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
