rust-gc VS ixy-languages

rust-langdev has a lot of libraries for building compilers in Rust. Perhaps you could use these to make your implementation easier, and revisit it later if you want to build things from scratch. I'd suggest logos for lexing, LALRPOP / chumsky for parsing, and rust-gc for garbage collection.

There's nothing stopping you from doing that in Rust. See rust-gc for an example of a GC implemented in Rust. Another example is mozjs, which is Rust bindings to SpiderMonkey. The GC there is implemented in C++, but it shows how you'd structure wrapper types for GC'd pointers in Rust so that you can use them safely, even with all the "ugliness" of a browser-grade GC.

One can have a GC as a library, https://github.com/Manishearth/rust-gc

The ones I am aware of are gc and broom. None will be as simple to use as the one in old Rust as userland implementations don't have the benefit of first-class integrated compiler support.

Rust has rust-gc, which is an attempt to add opt-in GC over Rust's more traditional automatic memory management. It's a neat project, but I'm not sure where it's actually being used.

Inb4 "already exists": the question is about making it convenient, not just imlementing the behavior.

There is also a library implementation of garbage collection for Rust, made by someone from the Rust core team.

Yep! And I'd actually fully agree those are garbage collection, there's also a crate by Manish which does """real""" garbage collection—https://github.com/Manishearth/rust-gc

I don't know that I'd say it "works" - it's never a technique I've needed to use myself, but it's the approach taken by e.g. https://github.com/Manishearth/rust-gc

Anyway, I found something recent that implements "rc" but in terms of tracing: https://github.com/Manishearth/rust-gc/ . Maybe useful for projects involving graphs of objects.

Not really, here it is winning hands down over Swift's ARC implementation.

https://github.com/ixy-languages/ixy-languages

You laugh, but ... https://github.com/ixy-languages/ixy-languages

GC'd languages are designed to leverage GCs, meaning they usually allocate a lot. Some of the more recent ones (C#, Go) have ways around it or to limit it, but in your average GC'd language you have to really bend yourself out of shape to limit allocations (IIRC the Ixy effort / study / thing never managed to make the Java hotpath allocation-free).

It's kind of funny when you see things like this project: https://github.com/ixy-languages/ixy-languages

like not-even-in-the-same-ballpark faster. In this realworld example (userspace network drivers in managed languages) JS manages about 20-30% of native code performance, python iirc is below 1%

- Support for generic-aware value types (struct vs. class) and low-level features like stackalloc: very valuable for high-performance scenarios and native FFI. See for instance https://github.com/ixy-languages/ixy-languages. In comparison, Java doesn't even have unsigned integers. Yes, Project Valhalla is coming someday.

As well, debatable to some folks, but: properties (get/set); operator overloading; LINQ > Java streams; extension methods; default parameters; collection initializers; tuples; nullable reference types; a dozen smaller features

Very bottom of this file https://github.com/ixy-languages/ixy-languages/blob/master/Java-garbage-collectors.md