[jkilpatr]

While I strongly agree this doesn't seem to match the sentiment of the paper.

Which is prioritizing a lower barrier to entry for new programmers at the cost of safety checks that help prevent humans from making mistakes at runtime.

It seems to me if our conclusion is humans, no matter how skilled, are flawed, we should be willing to do absolutely anything to lower the barrier to entry except removing checks on correctness.

[bjourne]

What makes you say that? What safety or correctness features do you think a garbage collector in Rust eschews? On the contrary, gc should make the language safer since it obviates the need for the "unsafe" escape hatch.

[adgjlsfhk1]

See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem.... The GC allows use after free bugs that are compile time exceptions in Rust.

[bjourne]

But the gc is there to test the usability cost of Rust's memory management scheme. A properly written gc would of course not allow for use-after-free bugs.

[adgjlsfhk1]

The problem is that this study is relatively worthless, because the API used by this GC inherently introduces UB. If you have a correct API, the usability tradeoff might be very different.

[bjourne]

Can you please point to some results in the study that would have been different if the tracing gc hadn't suffered from use-after-free bugs?

[steveklabnik]

To phrase what my sibling commentor said but in a different way:

This paper is an experiment to see if a particular API could make using Rust easier. This specific API is not sound. This means that the paper's results are kind of irrelevant in a strict sense; this API cannot work in Rust, so it being easier is kind of a moot point. Maybe someone can take their API, make it sound, and then try again, and that's certainly good. But it is a serious flaw in the methodology.

Specifically, this API call is unsound:

  GcRefCell<T>::as_mut(&self) -> &mut T

It's not about the internals of the GC. It's about the API that it exposes to users.

The author has some ideas: https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939... These ones are straightforward, and would probably work, but they would also introduce some friction, and removing friction is the entire point of the exercise. Is it too much? Maybe! It also maybe isn't. You'd need another study to figure that out.

[adgjlsfhk1]

The problem isn't that the GC suffered from use after free. The problem is that the GC allowed the user to have 2 references to a mutable object which is UB in Rust (and a compile time error without unsafe code). The problem with the API is that without some pretty fundamental changes to the language, the only times a GC doesn't error, and Rust does is when the user tries to do undefined behavior. Removing the UB is also pretty much impossible because if you allow these references, you remove one of the main tools the Rust compiler uses to optimize code.

[p0nce]

Quoting the article:

> those who [used the GC] required only about a third as much time (4 hours vs. 12 hours).

Surely you can devote a chunk of your newfounded time to find use-after-free bugs.

[adgjlsfhk1]

If that worked, people wouldn't still be finding use after free bugs in commonly used C libraries. The whole reason to use Rust is that it turns most of C's UB into compile time errors so that your code isn't horribly broken in the first place.

[notriddle]

I don't know how to find use-after-free bugs in arbitrary code, no matter how much time I devote to the task. I just can't keep enough state in my head at once.

[Lerc]

What does "use after free" mean in a garbage collected environment? Isn't the purpose of GC to automatically free after last use.

[adgjlsfhk1]

It means the GC design is fundamentally broken.

[jkilpatr]

> A key tradeoff is that Bronze does not guarantee thread safety

Data races are currently prevented by the borrow checker. Any GC in order to provide equivalent correctness would need to do so as well.

[dahfizz]

If you read the paper, they needed to throw out the thread safety from Rust's borrow checker in order to make the GC work. That is a massive surface area for bugs they are opening back up to make the language easier for beginners.

[mcoblenz]

I just added a clarification to the README about this. The main issue is that the current implementation keeps track of roots with a shadow stack technique (https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwr...), which is not thread-safe. It wasn't worth the engineering work for this particular study since the tasks didn't require more than one thread. A practical implementation, of course, would need to be thread-safe.

[dahfizz]

I'm sure the GC implementation itself could be made thread safe. But the paper mentions that Bronze lets you have multiple mutable references to an object. Doesn't this open the door to the user's code having data races, whereas it would be safe by default in vanilla Rust?

[bjourne]

Because their gc is a proof-of-concept created specifically for this research. It doesn't even deallocate memory. Most likely, they didn't have their students write any threaded code so thread-safety wasn't a concern. For a production ready tracing gc, of course they would add thread safety, it's not a big problem.

[dahfizz]

No, this is the fundamental tradeoff they made to make the Bronze'd Rust easy to use:

> Rust permits only one mutable reference to a value at a time... With Bronze, mutation is permitted through all references to each garbage-collected object, with no extra effort. A key tradeoff is that Bronze does not guarantee thread safety; as in other garbage collected languages, it is the programmer’s responsibility to ensure safety.

Allowing mutability anywhere is what fundamentally makes Bronze easier to learn, and more error-prone.

[bjourne]

The paper's author has already explained to you how thread safety can be achieved in a production-ready gc. This is not something that is particularly difficult to engineer and is quite orthogonal to whether one chooses to use tracing gc, ref counting or Rust-like borrow checking.