Hacker News Reader

Comment by verdagon | Hacker News Reader

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.

View on HN

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

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...

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.

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.

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.

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

> 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.

Reply on news.ycombinator.com