[bjourne]

The article does include a thorough description of the tasks. Afaict, none of them requires multiple mutable references to the same objects. It would be strange if any task did as it then wouldn't be implementable in plain Rust.

I think you are missing the point of this research. The author has, given his large sample size, persuasively demonstrated that Rust's borrow checker is confusing to newbies. Data from 428 students is a lot and an order of a magnitude more than many other programming language usability studies. This is in my opinion interesting research, even though I understand why Rust fans doesn't like his results!

[moltonel3x]

> Afaict, none of them requires multiple mutable references to the same objects

They ask to store objects ("turtles") into a single Vec. Two turtles from that Vec can breed to create a child turtle stored in that same vec. Parents must retain a reference (a real ref, not an index or other workaround) to their children, meaning that children have multiple refs. Children can become parents themselves, so all the turtles are mutable.

There you have it: multiple mutable references to the same object. With proper Rust you'll need some kind of RefCell to implement this (convoluted) design. The runtime check will ensure a runtime panic if you try to make the same object mutable via different RefCells (trying to breed a turle with itself). With BronzeGc the compiler will believe that they are different objects, and UB-optimize accordingly.

[steveklabnik]

I don’t think you understand why, given that as myself and several people have stated, the issue isn’t with the results. It’s with the methods. I have no opinion either way about the results, because as far as I can tell, they result from an incoherent premise, which means the conclusion is also incoherent.