Once you used lexical scoping, you're not going back to dynamic scope either, the same goes for the ability to reason about "where an object currently is" lexicographically.
I think Carp (https://github.com/carp-lang/Carp) is a much more interesting contender for a native clojure, simply because it has lexical ownership.
Doesn't the focus on immutable data make most of the ownership stuff redundant? My understanding was that ownership lets you be sure that you're the only mutable owner of a resource, or otherwise that you share the resource immutably. If data is (almost) always immutable, which seems to be a founding principle of Clojure, then what does ownership/borrowing buy you?
You are right in that immutability or more precisely the persistence that copy-on-write brings somewhat solves many of the issues that ownership also solves.
Persistence allows you to not care as much about who owns what, because whenever something is modified it is simply copied (with structural sharing), so you know that whatever you have is local anyways, not because you are the only one who has exclusive access to the thing, but because you make a copy of it at the point where answering that question would matter.
But you miss out on two things from that:
- Performance: Those copies are cheap but not free. Borrowing complements _persistent_ immutability in that regard extremely well, because it allows you to check if you're currently the only one using something and modify it mutably in that case. Clojure has a concept called transients, where you create an intermediately mutable version of an immutable thing to perform batch updates, but you still have to manage that yourself, with ownership it happens magically behind the scenes.
- Exclusive types: The other comment I wrote contains an example of this. I have an `ExclusiveID` type in my Database that is similar to a `row_id`. I can recover a lot of the capabilities of transactions and software transactional memory from these, simply because a user can rely on `ExclusiveID`s existing only at a single point at a time in their code. And `ExclusiveID` itself is a completely immutable thing, but the "contract" on how it can be used is what makes it powerful.
Immutability on a domain logic level also does not help you when it comes to dealing with inherently immutable things like devices and networks, whereas ownership does.
So I would argue that those two concepts are complementing each other extremely well, both implementation wise, but also in terms of a the mental model of how your code works.
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.
Java interop breaks things of course, much like unsafe Rust breaks guarantees of that language.
getFoo() = getFoo()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).
I used clojure professionally for a number of years and I can't remember ever really using it.
I.e. if you're not tracking ownership in new-lang, you're probably doing it very wrong.
Lexical scope allows you to reason about scope on a syntactical level.
Take this code:
let x = 5;
fn foo():
return x \* 2
fn bar():
let x = 10
return foo()
fn baz():
let x = "hello world!"
return foo()
bar()
With lexical scope you just don't know what's returned, for all you know x might not even be a number, but could be any type that just happens to be brought into scope.
Ownership is similar, in that you make the existence of a value a local property. If a 'thing' is inside a variable then you can move it somewhere else, but it also means that it is no longer in that variable. And that tracking of where what is, is a syntactical property, just like with lexical scope.
Clojure has software transactional memory. With ownership it wouldn't need half of the machinery (only that for rollback):
let blocked_accounts = Set()
let account_bob = new ExclusiveBankAccount(200)
let account_alice = new ExclusiveBankAccount(600)
// ExclusiveBankAccount cannot be copied or cloned
fn transfer(source_acc, target_acc, ammount):
if source_acc.deduce(amount.copy()):
target_acc.deposit(amount.copy())
fn block(acc):
let acc_identifier = acc.identifier.copy() // identifiers can be copied and are not exclusive
blocked_accounts.put(acc)
return acc_identifier
fn unblock(acc):
return blocked_accounts.take(acc)
fn do_invalid_stuff():
let good_account = new ExclusiveBankAccount(200)
let bad_account = new ExclusiveBankAccount(200)
block(bad_account)
transfer(bad_account, good_account) // <- this will fail because bad_account was moved by the block function and no longer exists here, it's invalid syntactically
fn do_valid_stuff():
let good_account = new ExclusiveBankAccount(200)
let bad_account = new ExclusiveBankAccount(200)
let ident = block(bad_account)
let restored_account = unblock(ident)
transfer(restored_account, good_account, 100)
- you can only transfer funds between two accounts in a thread safe way
- you can only transfer funds between accounts that are not blocked
Simply by not allowing something like this on a syntactical level you get a much cleaner understanding of what your code does. After a while you're wondering why we allowed anything else in the first place.
let x = thing();
let y = x; // the thing is moved from x to y here
print(x)
It's interesting you mention STM. That's one of the reasons I only dabble in Rust instead of switching over to it completely.
In do_invalid_stuff(),
block(bad_account)
transfer(bad_account, good_account) // <- this will fail
No. This will fail because in block the ownership of bad_account is lost. You’d need block(&bad_account) or block(&mut bad_account) to pass a reference while letting the transfer succeed. The only way the transfer would succeed silently like that is if Account implemented Copy (the compiler would automatically inject block(bad_account.clone())). This has nothing to do with threading (which Rust would still have protection mechanisms for). It would work identically if the block and transfer were member methods (i.e. bad_account.block(); good_account.transfer_from(bad_account)) since even member methods can be declared to be requiring ownership.
Right, but all the promises of the type system have to lead to a first-class multi-threading experience at some point.
The safest concurrent program isn't a single-threaded program.
Parent mentioned them above, argued that that ownership supersedes them,
>>> Clojure has software transactional memory. With ownership it wouldn't need half of the machinery (only that for rollback)
but then only showed a single-threaded demo of ownership. I don't need STM either if I'm only on a single thread.
STM's a good model. You just write code as if it were single-threaded, slap an 'atomically' around the lines which shouldn't be logically divisible, and you're basically done.
But "aquiring" them just looks like having them all in local scope, so there is no explicit `lock`.
In the transactional case you mentioned there can still be multiple transactions having access to the same values, so you need the explicit transaction semantics. Ownership never has such cases, unless you use locks to manage ownership between threads, but it could also be done via channels, or CSP, or whatever.
Put simply: How would two thread get access to the same account at the same time? There would be a point in time where the object would have to be split to end up in both of them, which would be invalid.
This is why you see things like this in rust
let x = 5;
let thread = thread::spawn(move || { // <- important bit
println!("{}", x);
});
println!("{}", x); // <- this would fail
Note that a value needs to be marked as `Send` so that it can pass across threads, but most types are.
That's what makes it so powerful. You know that any value you have in any variable, is only in that variable and nowhere else in the "world". Sure that value can be `Copy` and automatically copied, but that's still a new value. Your value can be `Sync` which means that a reference of it is `Send`, but you're not splitting up the value, you're creating and tracking a new reference value that is then send across the thread boundary.
(This is also why I walk past Erlang. Such emphasis on share-nothing prevents an account from being shared by a customer and a bank manager.)
So, what is the actual solution for a thread asking if any other thread has blocked(acct1), so that transfer() can proceed or be rolled back?
I’m not aware of any language that provides these kinds of guarantees statically or what that would even look like. You’re asking for a lot vs where the cutting state of language design is.
The way I solve situations like this is, by making sure that all accounts are moved to the same thread for a short period of time, which then handles the transaction. Which I find a lot easier to think about. It's essentially sharding by account and flexibly moving the shards into the same single writer context.
But if you want to do things the "old fashioned way" Rust provides plenty of classical synchronisation primitives like `Mutex` or `RwLock`.
You can also combine both approaches, e.g. have a single Mutex<AccountPool> that you can check out accounts from.
let x = 5
do_something_with(x)
do_something_with(x) // <- boom compiler error
But that's a bit cumbersome, so people add an operator that allows you to derive a new value from a variable without taking the old one. Let's call that one `&`. It takes a variable that would normally only have been allowed to be used once (because using it removes the value from it), and returns a "thing" that borrows the contents of the variable out, and behaves a lot like the original thing, but not quite.
let x = 5
do_something_with(&x)
do_something_with(&x)
The ability to track that only one of these can exist at any given moment for any value is based not on some special properties of "borrows" or "references", but because of the ability to uniquely track ANY value.
Carp is a very neat project, though it's not a Clojure. It's just Clojure-like. jank is Clojure.
My point was that ownership has become a language feature that I expect, like lexical scope has become a language feature that most people expect.
It complements persistent immutable data-structures extremely well, especially in terms of performance via automatic transient-ication, and if you're operating in the native space I can't imagine that performance isn't on top of the list.
So in that sense, great language, please consider evolving beyond Clojure (archaic?) ownership model, because I'm pretty tired of Rusts bloated syntax and lovecraftian macro system.