# Shifgrethor: garbage collection as a Rust library **URL:** https://internals.rust-lang.org/t/shifgrethor-garbage-collection-as-a-rust-library/8597 **Category:** Uncategorized **Created:** [October 17, 2018, 2:45pm UTC](https://internals.rust-lang.org/t/shifgrethor-garbage-collection-as-a-rust-library/8597 "2018-10-17T14:45:57Z") **Posts on this page:** 1 **Showing post:** 7
### Author: ![withoutboats](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/withoutboats/32/4560_2.png) [@withoutboats](https://internals.rust-lang.org/u/withoutboats) #### Post date: [October 18, 2018, 11:36am UTC](https://internals.rust-lang.org/t/shifgrethor-garbage-collection-as-a-rust-library/8597/7 "2018-10-18T11:36:24Z")
> [@felix91gr](#): > > That’s actually a very interesting point. From Rust’s “zero-cost abstractions” maybe there’s a way to implement GC’d languages _in GC’d Rust_ without much of a performance penalty. That’d be huge! You could start sharing code among different GC’d language projects, making Rust a really nice fit for them 😃 One potential use case for a GC library in Rust is to integrate with a _platform_ GC. For example, the WebAssembly platform will likely get native access to the GC of the associated JavaScript engine. This could be very impactful on the ability of Rust libraries to integrate with other languages running on that platform - not only JavaScript but also other GC'd languages compiled to wasm. However, the current WebAssembly GC proposal does not allow direct references into the GC the way that shifgrethor does, because it is intended to support copying collectors that do not have pinning. This means you couldn't use shifgrethor's API on top of that proposal. It's unclear to me how all of this will shake out, but shifgrethor is just trying to research the implications on GC APIs if we have this particular constraint (that we support direct references). --- _[View the full topic](https://internals.rust-lang.org/t/shifgrethor-garbage-collection-as-a-rust-library/8597)._