[libre-riscv-dev] Rust over C/C++

[Hendrik Boom]

On Fri, Jan 03, 2020 at 05:42:24AM -0800, Jacob Lifshay wrote:
> On Fri, Jan 3, 2020 at 3:51 AM Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> > The one serious probem I see with Rust is the inability to use a
> > garbage collector for those applications that do need one.
> >
> > I'd love to be able to use Rust's reliable allocation control for those
> > parts of a program where it's adequate, and a garbage collector for
> > those data where it isn't, and have Rust properly verify the interface
> > between them.
> 
> Well, Rust is quite nice because the language is good enough to build
> a garbage collector as a library that does just that, most likely
> without any special compiler support:
> 
> See:
> https://github.com/withoutboats/shifgrethor -- experimental GC library
> written by one of the core Rust devs.
> 
> Also a post by the author of https://crates.io/crates/gc (rather old
> post so some of it may be out-of-date):
> https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/

This paragraph from the last link looks like a warning that all was not well yet:

Of course, now we have to solve the problem of keeping track of the known reachable Gc<T>s, i.e. the roots. This is a hard problem to solve without language support, and I hope that eventually we might be able to get the language hooks necessary to solve it. LLVM has support for tracking
GCthings on the stack, and some day we may be able to leverage that in Rust.

And there's this from the first link:

Its an open problem to find new abstractable APIs which allow moving data only between traced memory locations, which would allow you to safely move Gc pointers around.

I wonder if things have changed since these were written.

-- hendrik

> 
> Jacob
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev