I am rather biased, but I think is a very poorly designed study. The GC design they present is likely not possible to make safe in the context of Rust with a "real" (nonleaking) implementation strategy, and the assignment they chose was deliberately one that requires tons of aliasing--but they did not provide students with the necessary knowledge or libraries to make that aliasing easier. Additionally, it contains gems like this:
> More Bronze participants withdrew from the study than Traditional participants (see section 7); the withdrawing Bronze participants may have been weaker, less industrious, or more risk-averse than the students that remained, leaving a stronger overall Bronze population compared to the traditional one.
I don't think there's anyone who's ever used Rust who thinks that it doesn't take way longer to learn or write graph data structures with just the borrow checker and no GC. So it's good to see people empirically establishing this fact, I suppose. But between the narrow nature of the task (a small toy problem that provides few opportunities to create aliasing bugs, while the borrow checker is intended to eliminate these bugs at scale), the unimplementability of the API, the unprofessional data analysis, and the lack of exposure of students to alternatives (such as TypedArena and Cell) that lack the problems of Rc<RefCell<_>>, I don't think much of the way it was conducted.
Just FYI..
"This version only includes the API for creating and using GC references; it does not actually collect anything."
[..]
".. the collector will not run; be aware that you will eventually run out of memory."
> More Bronze participants withdrew from the study than Traditional participants (see section 7); the withdrawing Bronze participants may have been weaker, less industrious, or more risk-averse than the students that remained, leaving a stronger overall Bronze population compared to the traditional one.
I don't think there's anyone who's ever used Rust who thinks that it doesn't take way longer to learn or write graph data structures with just the borrow checker and no GC. So it's good to see people empirically establishing this fact, I suppose. But between the narrow nature of the task (a small toy problem that provides few opportunities to create aliasing bugs, while the borrow checker is intended to eliminate these bugs at scale), the unimplementability of the API, the unprofessional data analysis, and the lack of exposure of students to alternatives (such as TypedArena and Cell) that lack the problems of Rc<RefCell<_>>, I don't think much of the way it was conducted.