If another function / sub-routine / thread / whatever alters this Thing while I'm looking at it, lots of nasty surprises await. For example maybe the Thing is a container of Objects and I was looping over it, taking out one object at a time and sometimes calling unrelated_function() but for some reason unrelated_function destroys the Thing occasionally and then... Boom, use-after-free.
It turns out that although we've often thought of this as a variety of different hard problems, including "data races" and "use after free", they're actually all one big problem, that of mutating something while somebody else used it. Solving this effectively solves all of those hard problems, at least in a subset of your language where you are able to address it.
In a language like C or C++ it's easy to make one or more references to a Thing, and then give away the references, or the Thing, or both, and then the programmer loses track (or maybe never knew they were related) and these nasty surprises are their reward.
In Rust, their borrowing / lending metaphor prevents the surprise. If you lend a mutable reference to the Thing, the borrower can't destroy it, that's not what "lending" means, and you can't even use it until they've stopped borrowing it. If you lend immutable references, nobody can destroy it, or mutate it at all, until all those references are given back. But this does make the language more complicated because of the new metaphor.
In Val, you can't have any references, so unrelated_function couldn't destroy Thing, you've got Thing, so unrelated_function doesn't have Thing and can't destroy it. No surprises.
> Solving this effectively solves all of those hard problems, at least in a subset of your language where you are able to address it.
No, "solving" this by preventing it in the first place just makes programming way too hard.
In practice, using something while other people are using it is perfectly fine in most cases. E.g. most Python programs do that, and most don't have bugs most of the time.
The "use-after-free" problem can far more easily be solved by removing `free` (e.g. by using Garbage Collection).
Most concurrency bugs remain even if you solve all data races (e.g. as Python does, with GIL) simply because the semantics are wrong (e.g. having to update 2 counters which cannot happen simultaneously), or iterating through a list while modifying it (no data races here if done from a single thread!).
And of course the trick is to avoid the nasty surprises and do do it in such a way that is still is easy to program. If you can only do it by adding additional hoops for a programmer to jump through (like having to annotate all your function parameters with lifetimes), it's not ideal. Val's subscripts are a nice idea; they make writing a function that returns a reference quite easy. On the other hand, it doesn't look as flexible as a regular function, so maybe it has the same amount of hoops, just different ones.
It turns out that although we've often thought of this as a variety of different hard problems, including "data races" and "use after free", they're actually all one big problem, that of mutating something while somebody else used it. Solving this effectively solves all of those hard problems, at least in a subset of your language where you are able to address it.
In a language like C or C++ it's easy to make one or more references to a Thing, and then give away the references, or the Thing, or both, and then the programmer loses track (or maybe never knew they were related) and these nasty surprises are their reward.
In Rust, their borrowing / lending metaphor prevents the surprise. If you lend a mutable reference to the Thing, the borrower can't destroy it, that's not what "lending" means, and you can't even use it until they've stopped borrowing it. If you lend immutable references, nobody can destroy it, or mutate it at all, until all those references are given back. But this does make the language more complicated because of the new metaphor.
In Val, you can't have any references, so unrelated_function couldn't destroy Thing, you've got Thing, so unrelated_function doesn't have Thing and can't destroy it. No surprises.