News for hackers. Stuff that matters.

A comment on Malloc envy. Parent comment

Re:Malloc envy by qznc on Monday April 04, 2016 @05:41PM (#11425924)
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.

[ Parent | on HN ]
Re:Malloc envy by Manishearth on Monday April 04, 2016 @06:20PM (#11426218)
It'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 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.

[ Parent | on HN ]
Re:Malloc envy by steveklabnik on Monday April 04, 2016 @05:47PM (#11425983) 

  > 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."
[ Parent | on HN ]