3 ms·

My biggest concern with the Gc ideas floating around Rust right now is that they may infect your program through dependencies. I guess I'm mostly worried about

My biggest concern with the Gc ideas floating around Rust right now is that they may infect your program through dependencies. I guess I'm mostly worried about Gc being used by a large number of libraries, to the extent that it might not matter if stdlib implements it or not, because by using some very popular library you'd end up pulling in this runtime dependency. Part of me loves the flexibility this will bring to application design, but it could be a slippery slope.

kibwen 10y ago
If such a popular GC-using dependency came into existence, then there would surely be demand for a drop-in replacement that didn't use GC. Remember, even the proposed Gc<T> type provides very little in the way of ergonomics (at least compared to garbage-collected types in pervasively-GC'd languages). Essentially it would just be a souped-up Rc<T> with no need for weak pointers to resolve cycles. Alternatively, it would only be used to interoperate with a foreign codebase that already uses GC, like SpiderMonkey or V8. Given that people tend to only be writing Rust in the first place if they put a large degree of value on performant solutions, I'm not too worried about the library ecosystem suddenly sneaking in GC everywhere, especially since the Rc type is already halfway to garbage collection, and I don't see it used unduly in the wild.
Manishearth 10y ago
It's not going to be something considered idiomatic, especially in a library. Rust support quite a few things which you're not supposed to use other than in exceptional circumstances (e.g. catching/recovering panics -- there has been no slippery slope yet). Nor will the stdlib expose a GC API. I do intend on writing an example GC for this, but really each use case will probably need its own special GC implementation; since they are special use cases. That's not a decision to take lightly. I don't think GC will be something that can be silently pulled in, either, since you will need to change your codegen flags at the top level. This could be abstracted away by cargo, but it might be better if it wasn't; and you have to explicitly tell cargo in the toplevel toml file that you want GC to be on (and get a compile error if you try to compile without those flags). ================== Also, the Rust community seems to be very careful about unnecessary costs. Even Rc<T> isn't used much, and when it is, it seems to be used at the application (not library) level. When I have to box a closure or iterator in Rust because `-> impl Trait` doesn't exist (where you can return anonymous types by specifying the trait they implement), I feel so annoyed by the cost. As do many other Rustaceans. In reality, this is a pretty rare thing to do and the costs are negligible; but it feels annoying to not have the best performance. In such an environment, I doubt a library that frivolously uses GC will survive.

kibwen 10y ago

If such a popular GC-using dependency came into existence, then there would surely be demand for a drop-in replacement that didn't use GC. Remember, even the proposed Gc<T> type provides very little in the way of ergonomics (at least compared to garbage-collected types in pervasively-GC'd languages). Essentially it would just be a souped-up Rc<T> with no need for weak pointers to resolve cycles. Alternatively, it would only be used to interoperate with a foreign codebase that already uses GC, like SpiderMonkey or V8. Given that people tend to only be writing Rust in the first place if they put a large degree of value on performant solutions, I'm not too worried about the library ecosystem suddenly sneaking in GC everywhere, especially since the Rc type is already halfway to garbage collection, and I don't see it used unduly in the wild.

Manishearth 10y ago

It's not going to be something considered idiomatic, especially in a library. Rust support quite a few things which you're not supposed to use other than in exceptional circumstances (e.g. catching/recovering panics -- there has been no slippery slope yet). Nor will the stdlib expose a GC API. I do intend on writing an example GC for this, but really each use case will probably need its own special GC implementation; since they are special use cases. That's not a decision to take lightly. I don't think GC will be something that can be silently pulled in, either, since you will need to change your codegen flags at the top level. This could be abstracted away by cargo, but it might be better if it wasn't; and you have to explicitly tell cargo in the toplevel toml file that you want GC to be on (and get a compile error if you try to compile without those flags). ================== Also, the Rust community seems to be very careful about unnecessary costs. Even Rc<T> isn't used much, and when it is, it seems to be used at the application (not library) level. When I have to box a closure or iterator in Rust because `-> impl Trait` doesn't exist (where you can return anonymous types by specifying the trait they implement), I feel so annoyed by the cost. As do many other Rustaceans. In reality, this is a pretty rare thing to do and the costs are negligible; but it feels annoying to not have the best performance. In such an environment, I doubt a library that frivolously uses GC will survive.