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.
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
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.
According to the author: "The Bronze project is exploring the usability costs of the restrictions that Rust imposes."
That does not require a sound gc to explore. Maybe it would have been different had the goal been to see whether a gc can be bolted onto Rust. Yes, that might be difficult given Rust's semantics and how to deals with pointers. But that doesn't seem to be the goal of the author's research.
There are other GC crates that offer sound APIs. Research using those sounds very promising and good!
It matters because the rest of the Rust universe follows this pattern. If they coded their own standard library (and any other allowed libraries) and modified the compiler to not miscompile this usage, then that exploration would be valid. But you’re also going to get friction from miscompiles and fighting with other APIs that do have this property. So it would be more useful to either go all-out ok this idea that Rust’s uniqueness properties are a bad thing, or fix the soundness issues. The halfway step simply confounds too many issues to be truly useful, in my opinion.
I agree that exploring the space is a good idea and useful. My issue is with the methodology, not the concept.
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!
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.
This would be the most idiomatic approach, yes. They could use a code transformation to automate the 'wrapping' and present an intuitive, frictionless interface to the developer.
This is correct.
> because the memory manager cannot detect use-after-free errors.
... this is not. It is UB because the language declares it UB. It is absolutely to the core of the design of the language itself. All Rust code relies on this property to work. Something that breaks it is in fact broken, regardless of any other aspect of the program.
> 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.
Data races are currently prevented by the borrow checker. Any GC in order to provide equivalent correctness would need to do so as well.
> 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.
And yet the folks maintaining the network stack in the Linux kernel are not anywhere near what I or almost anyone else would consider the lowest common denominator programmer.
Sometimes you just have to accept that ALL humans are inherently bad at this, only some are worse than others at various points in their lives. The security and reliability of the product of our output should not be so largely dependent upon our ability to get a full night's sleep, reasonable working hours, and lack of personal conflict. To be sure, we should all strive for those things, but perhaps the choice of tools is correct in prioritizing mitigation of difficulties and vulnerabilities from meatspace.
Sometimes that's a borrow checker. Other times it's a garbage collector. And every once in a while, we need to break out an unsafe block (or the entire C language) to get a job done.
Considering how much more expensive people are than software or hardware, the trade off for easier/simpler access is increasingly straightforward.