> If data is (almost) always immutable, which seems to be a founding principle of Clojure
Being immutable isn't some "best-practice" like eating your veggies, where the more you eat, the healthier you are, and occasional sugar is OK.
I either can reuse the result of getFoo() or I can't. If getFoo() is 99% immutable - as the caller, it's my job to consider taking locks and/or making defensive copies.
If I want to publish library code that calls getFoo(), now my callers will need to consider taking locks and/or making defensive copies.
Your question was about Rust ownership, and I answered about Haskell immutability - but they're both the same in that they're pretty strict compiler rules, and you have to stray into unsafe territory to violate them.
I am not sure where "almost" came from. Data in Clojure is 100% immutable? You can pass around data between functions or between threads and never worry about anyone modifying it. I believe Clojure is less strict about I/O than what Haskell is(?), but once some data has been created it can not be modified. Any modification will return a new thing, never modify the original thing.
Java interop breaks things of course, much like unsafe Rust breaks guarantees of that language.
Given some Clojure function getFoo() which only calls into the Clojure std lib, and doesn't call any function with 'unsafe' (or similar) in the name, is it always true that:
Functions are not always pure, no. Clojure is not so strict about I/O, meaning that function could for instance call out to make a database request. But I think that is unrelated to immutability or ownership of data?
Immutability guarantees if I call getFoo(x) I can trust that nothing happens to x (assuming x is proper Clojure data and not some unsafe other thing like a Java Object). And getFoo can likewise return anything without there being any risk that anyone else modifies that thing. It does not matter who owns x or who owns the return value from getFoo, since no one is able to modify those things anyway.
* Database request was a bad example as, as far as I know, there is nothing built-in for supporting that, so that would already be in unsafe Java territory. But there are non-pure functions built into the Clojure standard library that getFoo could call to return different results on the same input, like slurp or deref, and probably many other ones (I have not used Clojure for a long time).
Being immutable isn't some "best-practice" like eating your veggies, where the more you eat, the healthier you are, and occasional sugar is OK.
I either can reuse the result of getFoo() or I can't. If getFoo() is 99% immutable - as the caller, it's my job to consider taking locks and/or making defensive copies.
If I want to publish library code that calls getFoo(), now my callers will need to consider taking locks and/or making defensive copies.
Your question was about Rust ownership, and I answered about Haskell immutability - but they're both the same in that they're pretty strict compiler rules, and you have to stray into unsafe territory to violate them.