4 ms·

That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're

That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're not free'ing or malloc'ing), we just get a different instance of the same type, which is memory-safe. You do bring up a valid broader concern. Ironically, this is a reason that GC'd systems can sometimes be better for privacy than Ada or Rust which uses a lot more Vec+indexes. An index into a Vec<UserAccount> is riskier than a Java List<UserAccount>; a Java reference can never suddenly point to another user account like an index could. But that aside, we're talking about memory safety, array-centric approaches in Zig and Rust can be appropriate for a lot of use cases.

pjmlp 4y ago
In high integrity computing that is pretty much safety related, if that logic error causes someone to die due to corrupt data, like using the wrong radiation value.
- deleted 4y ago
  [deleted]
tialaramex 4y ago
But, Java has exactly the same behaviour, the typical List in Java is ArrayList which sure enough has an indexed get() method. There seems to be no practical difference here. Rust can do a reference to UserAccount, and Java can do an index into an ArrayList of UserAccounts. Or vice versa. As you wish.
- verdagon 4y ago
  In Java, you can hold onto a reference to the UserAccount directly, for as long as you want. The borrow checker, however, forces you to hold onto an index instead.
  - anonymoushn 4y ago
    Right, it sounds like you are circumventing the borrow checker and then experiencing some of the classes of bugs it was supposed to prevent. And this seems common: https://www.youtube.com/watch?v=4t1K66dMhWk https://www.youtube.com/watch?v=4t1K66dMhWk
    - verdagon 4y ago
      > Circumventing the borrow checker Programs often require inherent state with data that refers to other data. In these cases, one must circumvent the borrow checker, whether it be with indices, IDs, Rc, or whatever. The borrow checker simply does not allow changing data when someone has a reference to it (except for the rare case where we can use Cell). It's a myth that we can rewrite any program to not circumvent the borrow checker.
veber-alex 4y ago
If you are holding indexes to a collection and plan to delete elements you will never use Vec. There are dedicated data structures for this [1] that will not let you access another item by mistake. [1] https://crates.io/crates/slotmap https://crates.io/crates/slotmap
- verdagon 4y ago
  You should never use Vec in that situation, but we see it all the time. People love indexing into Vecs and reusing elements. One of my favorite alternatives is generational_arena [0] which also happens to be the library that inspired Vale's generational references! [0] https://docs.rs/generational-arena/latest/generational_arena/ https://docs.rs/generational-arena/latest/generational_arena...

pjmlp 4y ago

In high integrity computing that is pretty much safety related, if that logic error causes someone to die due to corrupt data, like using the wrong radiation value.

deleted 4y ago
[deleted]

tialaramex 4y ago

But, Java has exactly the same behaviour, the typical List in Java is ArrayList which sure enough has an indexed get() method. There seems to be no practical difference here. Rust can do a reference to UserAccount, and Java can do an index into an ArrayList of UserAccounts. Or vice versa. As you wish.

verdagon 4y ago
In Java, you can hold onto a reference to the UserAccount directly, for as long as you want. The borrow checker, however, forces you to hold onto an index instead.
- anonymoushn 4y ago
  Right, it sounds like you are circumventing the borrow checker and then experiencing some of the classes of bugs it was supposed to prevent. And this seems common: https://www.youtube.com/watch?v=4t1K66dMhWk https://www.youtube.com/watch?v=4t1K66dMhWk
  - verdagon 4y ago
    > Circumventing the borrow checker Programs often require inherent state with data that refers to other data. In these cases, one must circumvent the borrow checker, whether it be with indices, IDs, Rc, or whatever. The borrow checker simply does not allow changing data when someone has a reference to it (except for the rare case where we can use Cell). It's a myth that we can rewrite any program to not circumvent the borrow checker.

veber-alex 4y ago

If you are holding indexes to a collection and plan to delete elements you will never use Vec. There are dedicated data structures for this [1] that will not let you access another item by mistake. [1] https://crates.io/crates/slotmap https://crates.io/crates/slotmap

verdagon 4y ago
You should never use Vec in that situation, but we see it all the time. People love indexing into Vecs and reusing elements. One of my favorite alternatives is generational_arena [0] which also happens to be the library that inspired Vale's generational references! [0] https://docs.rs/generational-arena/latest/generational_arena/ https://docs.rs/generational-arena/latest/generational_arena...