One observation I have with Rust, looking at the code in wild, abstractions are usually (always?) leaky - implementation details are exposed/imposed due to the ownership feature of the language.
Ownership is not implementation. Ownership is contract. If you’re an owner of a house you can do more than if you’re only renting and if you’re renting you can do more than if you’re only looking at the house from the street. Ownership is a very useful concept that influences interfaces in real life so why wouldn’t it in programming?
This reads like the Rust equivalent of the OOP 'animal/cat/dog' intros of yore. Real world comparisons are almost never all that helpful when it comes to computing concepts.
Ok, point taken, indeed it reads like that. However, in programming and generally in engineering this is a very useful concept. There is a difference between "component X is part of Y" than "component X works / interacts with Y" or "component X has exclusive access to Y in this particular span", similarly how it is often very important to know if "component X can be safely shared" - and Rust allows to express that, while languages like Java are quite blind to that.
Consider a simple Java method signature:
public static MyCustomFileReader open(FileHandle someFile) { ... }
Who is responsible for closing the file after you're done with reading it?
Does the returned reader close the file handle on close, or should I issue another close on the file handle afterwards?
Can I open multiple readers on the same file? The only way to know is to check the javadoc comment, if someone took time to write it. In Rust there are no doubts like that.
