8 ms·

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

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 5y ago
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.
- jkilpatr 5y ago
  > 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 5y ago
  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.
  - bjourne 5y ago
    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 5y ago
      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 5y ago
        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.
  - mcoblenz 5y ago
    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-gcwrite 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 5y ago
      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?
- adgjlsfhk1 5y ago
  See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679 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.
  - p0nce 5y ago
    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 5y ago
      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 5y ago
      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.
  - bjourne 5y ago
    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 5y ago
      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 5y ago

bjourne 5y ago

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.

jkilpatr 5y ago
> 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 5y ago
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.
- bjourne 5y ago
  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 5y ago
    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 5y ago
      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.
- mcoblenz 5y ago
  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-gcwrite 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 5y ago
    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?
adgjlsfhk1 5y ago
See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679 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.
- p0nce 5y ago
  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 5y ago
    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 5y ago
    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.
- bjourne 5y ago
  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 5y ago
    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 5y ago