3 ms·
Are you familiar with the D programming language? They think a lot about these issues. By default D uses a GC for classes (allocated on the heap, Java-style).
by qznc 11y ago
Are you familiar with the D programming language? They think a lot about these issues.
By default D uses a GC for classes (allocated on the heap, Java-style). You can disable/avoid the GC with some additional effort and the language tries to help. For example, there is a @nogc annotation, which emits an error for anything which could trigger the GC, although it does not prevent a stop-the-world event from another thread.
Rust is kind the inverse approach. Currently, there is no GC and real time is (relatively) easy. Now they try to introduce an optional GC for convenience.
Mixing GC with (real time) non-GC code is quite desirable, but I have not seen an elegant approach, yet.
- steveklabnik 11y ago> Now they try to introduce an optional GC for convenience. Most of the GC work in Rust, at least at this time, is more about integrating with external GCs. Think "Servo uses javascript objects that Spidermonkey controls" or "A Ruby gem in Rust lets the Ruby GC deal with Ruby objects."
- Manishearth 11y agoIt's not exactly for convenience. The Rust GC support isn't intended to be used in general situations. It's for integrating with languages/applications that have a GC, like spidermonkey or V8. https://github.com/manishearth/rust-gc https://github.com/manishearth/rust-gc actually lets you cleanly mix GC and non-GC heap objects (even put pointers to GC heap objects on the malloc heap and vice versa). So does Servo's current bindings to spidermonkey.