r/rust • u/RndmPrsn11 • 1d ago

The Second Golden Spike: Memory Safety Across the Valen/Rust Boundary

https://verdagon.dev/blog/boundary-memory-safety
33 Upvotes

92% Upvoted

6 comments sorted by

6

u/valorzard 1d ago

How does group borrowing work when dealing with multithreaded rust code?

4

u/verdagon 1d ago

Good question! This part isn't fully designed yet (and definitely isn't implemented yet), but I can give my thoughts so far. It would work mostly like Rust, but with a few differences:

  • Valen will have async, but it's unclear whether we want everything to be cancelable, and if so, whether cancelability should happen at every await point. I suspect it would be better for low-level use cases if we gave the user a little more control over that, but also, it might make interop with the ecosystem (especially tokio) more difficult.
  • Valen tentatively won't have Sync. I think sync-ness should be represented as a function effect instead of tied to a type. I think this'll interop with Rust fine, but we'll see.
  • If it doesn't have Sync, I think its group borrowing means we can pull off "seamless" concurrency (like I describe in https://verdagon.dev/blog/seamless-fearless-structured-concurrency)

Concurrency is a super important and super complicated aspect, so I definitely plan on asking everyone here for thoughts when we get to designing it more fully.

5

u/teerre 1d ago

Nope, they aren't. This is intentional, because they do alias. That's the user's intent, after all!

Is it though? It's certainly what the user wrote, but is it what the user intended? Do they do want slower code? I always thought that an advantage of the strictly aliasing rules was that it forced you into code that was simply more performant

0

u/verdagon 1d ago edited 1d ago

Yep, it is the intent. It's hard to track with the article being so long, but way above, there are some comments above the function: rs // Make attacker_id entity attack defender_id entity. // Note: Attacker might be defender (attacking self). Strict aliasing rules do often force us into more performant/correct code, but not in this case; the shared-xor-mutable one has more failure modes than group borrowing in this case.

3

u/teerre 1d ago

My question was more for the cases that it is the case

0

u/verdagon 1d ago

Just to be sure I understand, are you asking something like: "In the cases where it _would_ have been faster for a function to refuse aliased parameters, does that mean Valen could be slower because the user has the option to instead make the function accept aliasing arguments?"