Comment by verdagon

While technically true, I'm not sure that the iterator invalidation argument is that strong in practice. Rust doesn't seem to eliminate those problems, it more moves them around and transforms them into different (though sometimes easier) problems.

We often think that the borrow checker protects us from these kinds of mutability conflict / single-threaded race conditions, by making it so we don't have a reference to an object while someone else might modify it. However, the classic workaround is to turn one of those references into an index/ID into a central collection. In real programming, that index/ID is equivalent to the reference. But while I hold that index/ID, the object can still change, which kind of throws the benefit into question.

In other situations where we only have multiple read-only references, there's not really a motivating problem to begin with, even when coded in other languages that don't also regard them as read-only.

I think the other benefits the article mentions (concurrency benefits, plus encouraging into flatter, cleaner architectures) are a bit more compelling.