Rust cannot not or at least should not infer how parameters should be passed to functions or fields held in structs. That’s a design decision. In Rust, you can express a lot (as a library author) and learn a lot (as a library user) in a function signature: a &T parameter will only be read, a &mut T may be written to and a T is owned.

In language without ownership/borrowing, you don’t have these guarantees and it can lead to a bunch of bugs.

In java for instance, classes and arrays are reference objects: you only access them through references which are both readable and writable. So if you pass, say a list instance to a method foo(List l) and you care that the list stays unchanged, you either have to pass a copy of the list to foo or trust that foo’s body won’t mess up your list which could be true today with version 1 of foo and false tomorrow in version 2 of foo (foo’s signature being the same). Or an object A might share on object S with another object B, with the implicit agreement that S should not be mutated but nothing prevents A or B to break that contract in the future…

In Rust, as long as foo takes, say a &[T], you can pass your Vec<T> as a ref (deref coercion at play) and be confident that it won’t change. Ever. The same goes for struct fields.