Efficient GC requires tight integration with LLVM, and I assume that means also tight integration with the Rust compiler. I don't think that can be done as a library or even a plugin.
Rust doesn't need an efficient GC like the kind Java has. Most of the resources you need in Rust are freed when they get out of scope.
What Rust needs is just a better RC implementation. This is because only a small part of your data is reference counted, so it fits better with how Rust works, so an efficient implementation allows it to combine with ownership semantics to outperform even very advanced generational GCs.
> I'm hoping WebAssembly doesn't inherently imply a runtime.
The present documentation seems to suggest that it won't really include a full-blown runtime, but may include a small number of builtin modules:
"The WebAssembly spec will not try to define any large portable libc-like library. However, certain features that are core to WebAssembly semantics that are found in native libc would be part of the core WebAssembly spec as either primitive opcodes or a special builtin module (e.g., sbrk, mmap)."[1]
This brings up the natural question of libraries and dependency management in WASM. Will there be a WebAssembly equivalent of Maven/npm/et al.?
As a library that would ideally tie into the compiler to implement a real, tracing, copying GC. Something close to that is already done with Servo's Spidermonkey GC integration.
With WebAssembly, it sounds like they want the same sort of thing- let manual/Rust-style/etc. memory management work, but still allow the necessary integration into the runtime for a GC.
You can have APIs without a runtime. For instance, the WebAssembly implementation should have a function to spawn a new thread given a function pointer. That should result in a real OS thread running in the same address space. Any further semantics beyond that would be up to the software targeting WebAssembly.
I'm hoping WebAssembly doesn't inherently imply a runtime.