Hmm.. Rust was created to support the new browser, browsers mainly manage DOM objects.. I wonder why you are using a legacy garbage collector in order to handle primary tasks rather than having that part of your core design?

SpiderMonkey's GC is very modern, it's not legacy at all. Furthermore, while Servo influences the design of Rust, it does not dictate the design of Rust (or else, for example, Rust would have had struct inheritance years ago).

Spidermonkey uses generational gc with some kind of compacting these days. Why do you think that's legacy? What models are strictly better than that?

Irrelevant here.

For Servo we need a javascript engine. We're already using Spidermonkey. It has a GC for Javascript; we're already paying those costs. The Rust-side representation of DOM objects is also managed by the GC; that makes sense because these are tied to Javascript things.

We don't use the GC elsewhere. I think at some point we did, but the only place now in Servo where GC is used is where the data is strongly connected to data already managed by the SM GC.

Nim's GC is for general-purpose use in a language. Spidermonkey's GC is for GCing javascript, which already has an extensive runtime (which the GC ties into heavily). "Nim's GC is better than Spidermonkey's" is a statement of no value (and oversimplifies the situation) unless the context is specified. Using the SM GC to collect random Rust objects would be a bad idea. Somehow rigging up spidermonkey to use a Nim-like GC in Rust (all other things being the same) would also be a bad idea. Two different scenarios, two different GCs.

No, it's not. Generational, incremental, precise GC generally outperforms non-generational, non-incremental, conservative deferred reference counting.

Because rewriting Spidermonkey is both tedious and doesn't benefit from Rust safety guarantees.