3 ms·

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

by zerr 2y ago

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.

pkolaczk 2y ago
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?
- flohofwoe 2y ago
  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.
  - pkolaczk 2y ago
    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.
maxbond 2y ago
Could you give an example?
mejutoco 2y ago
Without more details it sounds like what you are saying is there are constraints due to the ownership model. That is not a leaky abstraction. You can also bypass some constraints, but need to be explicit about it.

by zerr 2y ago

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.

pkolaczk 2y ago

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?

flohofwoe 2y ago
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.
- pkolaczk 2y ago
  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.

maxbond 2y ago

Could you give an example?

mejutoco 2y ago

Without more details it sounds like what you are saying is there are constraints due to the ownership model. That is not a leaky abstraction. You can also bypass some constraints, but need to be explicit about it.