A better metric for whether you think about it or not would be at refactor time. In Java, you can just move something around in any way or shape, change its li

A better metric for whether you think about it or not would be at refactor time. In Java, you can just move something around in any way or shape, change its lifetime semantics very liberally (e.g. make it have a single instance, or make every thread have its own, or make it have its own instance of X as a field, or just use a shared one), and it will compile without a word and the runtime will handle it. In rust, in my experience (though it is surely significantly less than Yours), these kind of refactors actually require code changes at almost every location, and might recursively cause further such issues. I think there is a sort of bias here as well, that people kind of like this kind of refactor where the tooling readily shows you the exact error and it may not be too difficult to solve each case, so this might not register as annoying, but quite obviously a stricter lifetime system will have to have some downsides as well.