2 ms·

I think it’s less about the runtime and more about nailing down and stabilizing the implementation details. GCs have a lot of subtle trade offs just like async

I think it’s less about the runtime and more about nailing down and stabilizing the implementation details. GCs have a lot of subtle trade offs just like async runtimes (i.e. like the decision to require Send + Sync versus single threaded Futures) where there’s no obvious sane default. There’s too much variation in what the community needs from a GC compared to something like a HashMap where a general implementation works fine with options to change the hasher or allocator covering >90% of use cases.

zozbot234 2y ago
I think most async runtimes give you the option of launching a single-threaded executor when you explicitly request it. AIUI the most esoteric tradeoffs wrt. GC involve how to have data representations that can be efficiently traced, and whether you should allow e.g. moving data in memory as part of the collection phase. But I think you're overestimating somewhat the variation within the Rust-focused community - given what most Rust code looks like, they're going to be mostly interested in something straightforward yet efficient, that can interoperate with existing Rust code w/ relative ease while addressing the common issue of cyclical data references.