It's very hard to retrofit the rules that the borrow check enforces onto an existing language. That's because the borrow check enforces "aliasing xor mutability", and basically all languages in wide use don't enforce that. Adding that to an existing language generally requires breaking backwards compatibility in fundamental ways.
For example, all non-immutable objects in garbage-collected languages (or similar features such as shared_ptr in C++) are incompatible with these restrictions. As another example, mutable global variables are generally incompatible with the semantics that the borrow check enforces.
That said, I could see analogous dynamic systems (rather than static ones as in the case of Rust) becoming more widespread. In fact, Transferables [1] in JavaScript are an example of one such system.
Hmm, what about wrapping everything in an Arc<RwLock<...>> and gradually removing the wrappers (and the extra method calls) from each variable, backtracking on compiler errors?
Swift is likely to adopt it but it a much more measured way, since everything is `shared_ptr` by default in that language. Relatively few languages have the combination of requirements and goals that makes Rust's approach obligatory and necessary.
So if it's successful we should see more of it but...we won't necessarily see many languages where it is as all-pervading as Rust.
Swift's tentative plan seems to be to have a level between regular swift and super unsafe swift with UnsafePointer and stuff where you can write fast, low level, but safe code like Rust.
In swift's case I'd think they would avoid too much complexity since the lifetime stuff won't be as pervasive as it is in Rust (so it can have more rough corners)
Given the current state of the borrow checker and how lifetimes are handled inside closures, essential for callbacks, I think in its current state anything close to Cocoa or Cocoa Touch would be quite hard to implement and use in Rust, unless it is full of Rc and RefCell everywhere.
