| The way I would frame this is that Rust has static (compile-time) memory management, and that conflicts with dynamic memory management (garbage collection). The boundary is awkward and creates complexity. I wrote a post about problems writing a garbage collector in C++, e.g. annotating the root set, and having precise metadata for tracing. http://www.oilshell.org/blog/2023/01/garbage-collector.html https://news.ycombinator.com/item?id=34350260 I linked to this 2016 post about Rust, which makes me think the problem could be worse in Rust, although I haven't tried it: http://blog.pnkfx.org/blog/2016/01/01/gc-and-rust-part-2-roo... I didn't write as much about bindings to native C++ code, but that's also an issue that you have to think about carefully. CPython has kind of been "stuck" with their API for decades, which exposes reference counting. So it's extraordinarily difficult to move to tracing GC, let alone moving GC, etc. --- On the other hand, there was also a paper that said Rust can be good for writing GCs. Rust as a Language for High Performance GC Implementation https://dl.acm.org/doi/pdf/10.1145/2926697.2926707 However, I'm not sure it addresses the interface issue. One lesson I learned is that GCs are NOT modular pieces of code -- they have "tentacles" that touch the entire program! That said, C++ is pretty good at "typed memory" as well, and I think it's more pleasant than C. That is, you get more than void* and macros. So I can believe that Rust has benefits for writing GC. Not sure about Zig -- I can believe it's a nice middle ground. |
(Safe) Rust indeed limits the user to a compile-time deallocable subset of what’s expressible (RC being an escape hatch), which depending on the problem domain may be too limiting.