Earlier quoted context omitted.
Aside from game dev, Rust is being used in quite a lot of green field work where C++ would have otherwise been used. Game dev world still has tons of C++, but also plenty of C#, I guess. Agreed that it’s not really behind us though. Even if Rust gets used for 100% of C++’s typical domains going forward (and it’s a bit more complicated than that), there’s tens? hundreds? of millions (or maybe billions?) of lines of wo…
The problem in Rust is that if B is inside of A, struct A { name: String, owned: B } struct B { name: String, } you can't have a writeable reference to both A and B at the same time. This is alien to the way C/C++ programmers think. Yes, there are ways around it, but you spend a lot of time in Rust getting the ownership plumbing right to make this work.
I think you maybe meant to say something different because here's the most obvious thing:
impl A {
fn simultaneously_writeable(&mut self) -> (&mut str, &mut str) {
(&mut self.name, &mut self.owned.name)
}
}
Did you perhaps mean simultaneous partial field borrows where you have two separate functions that return the name fields mutably and you want to use the references returned by those functions separately simultaneously? That's hopefully going to be solved at some point, but in practice I've only seen the problem rarely so you may be overstating the true difficulty of this problem in practice.
Also, even in a more complicated example you could use RefCell to ensure that you really are grabbing the references safely at runtime while side-stepping the compile time borrow checking rules.