Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths:

- Rust has no overhead from a "framework"

- Rust programs start up quickly

- The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff

- The strict nature of the language helps guide the programmer to write bug-free code.

In short: There's a lot of good reasons to choose Rust that have little to do with the presence or absence of a garbage collector.

I think having a working garbage collection at the application layer is very useful; even if it, at a minimum, makes Rust easier to learn. I do worry about 3rd party libraries using garbage collectors, because they (garbage collectors) tend to impose a lot of requirements, which is why a garbage collector usually is tightly integrated into the language.

For those who are interested, I think that arena allocation is an underrated approach to managing lifetimes of interconnected objects that works well with borrow checking.

I don’t understand the desire to staple a GC into Rust.

If you want this, you might just…want a different language? Which is fine and good! Putting a GC on Rust feels like putting 4WD tyres on a Ferrari sports car and towing a caravan with it. You could (maybe) but it feels like using the wrong tool for the job.

Memory safety would be a good idea indeed. Just to get rid of the unsafeties in the stdlib and elsewhere. With this would also go type-safety, because there will be no more unsafe hacks. Concurrency safety would another hill to die on, as they choose not to approach this goal with their blocking IO and locks all over.

While I'm not ideologically opposed to GC in Rust I have to note:

- the syntax is hella ugly

- GC needs some compiler machinery, like precise GC root tracking with stack maps, space for tracking visted objects, type infos, read/write barriers etc. I don't know how would you retrofit this into Rust without doing heavy duty brain surgery on the compiler. You can do conservative GC without that, but that's kinda lame.

> Having acknowledged that pointers can be 'disguised' as integers, it is then inevitable that Alloy must be a conservative GC

C# / dotnet don't have this issue. The few times I've needed a raw pointer to an object, first I had to pin it, and then I had to make sure that I kept a live reference to the object while native code had its pointer. This is "easier done than said" because most of the time it's passing strings to native APIs, where the memory isn't retained outside of the function call, and there is always a live reference to the string on the stack.

That being said, because GC (in this implementation) is opt-in, I probably wouldn't mix GC and pointers. It's probably easier to drop the requirement to get a pointer to a GC<T> instead of trying to work around such a narrow use case.

I'm curious about the applicability.

If memory management is already resolved with the borrow checker rules, then what case can make you want a GC in a Rust program?

No has seemed to call it out yet but swift uses a form of garbage collection but remains relatively fast. I was against this at first but the more I think about it, I think it has real potential to make lots of hard problems with ownership easier to solve. I think the next big step or perhaps an alternative would be to make changes to restrictions in unsafe rust.

I think the pursuit of safety is a good goal and I could see myself opting into garbage collections for certain tasks.

The whole point of Rust is to not have a garbage collector while not worrying about memory leaks, though.

There was one time where I actually had to use object resurrection in a finalizer. It was because the finalizer needed to acquire a lock before running destruction code. If it couldn't acquire the lock, you resurrect the object to give it a second chance to destroy (calling GC.ReRegisterForFinalize)

While it might be useful for exploration/academic pursuit/etc., am I the only one who finds "conservative GC" a non-starter? Even if this was fully production ready, I had a use case for it, etc. I still would never ship an app with a conservative GC. It is difficult enough to remove my own bugs and non-determinism, and I just can't imagine trying to debug a memory leak caused due to a conservative GC not finding all used memory.

I have thought for years Rust needs to bifurcate.

Asyc/await really desperately needs a garbage collector. (See this talk from Rustconf 2025: https://youtu.be/zrv5Cy1R7r4?si=lfTGLdJOGw81bvpu and this blog:https://rfd.shared.oxide.computer/rfd/400)

Rust that uses standard techniques for asynchronous code, or is synchronous, does not. Async/await sucks all the oxygen from asynchronous Rust

Async/await Rust is a different language, probably more popular, and worth pursuing (for somebody, not me) it already has a runtime and the dreadful hacks like (pin)[https://doc.rust-lang.org/std/pin/index.html] that are due to the lack of a garbage collector

What a good idea

Very important paper.

If only there was a C++-like language with garbage collection (Java, C#, etc)