[…] Rust’s rules around lifetimes [though] usually framed in the public consciousness as “a way to avoid garbage collection,” […] are a much deeper and more significant construct than that. They are […] an incredibly powerful tool for understanding the behavior of the system because you can analyze [it] locally: you never need to worry about “spooky action at a distance.” And you can do so without manually reconstructing imperative control flow with monads. As I’ve written several times before: monads are a clever way to show you can program without mutation; lifetimes are an even cleverer way to show you can just use mutation.
This is the single “deepest” lesson that I feel like I’ve learned about Rust so far. Lifetimes, stumbled upon while trying to avoid (runtime) garbage collection, are in fact a more general tool for delimiting behavior/causality in programs.
I’m not saying that Rust’s solution is perfect. Indeed, lifetime syntax is arcane and confusing to users. But I think any solution that claims to beat Rust should provide the same level of guarantee or indeed better: ideally new languages would allow for imperative programming without any shared mutable state at all.
Similarly, this aligns with my current opinion of rust vs other programming languages for tasks that are not inherently unsuited to Rust’s current state.
I’m not sold on the idea of “imperative programming without any shared mutable state at all”. Maybe I just can’t accurately imagine what that would look like in practice.
I’m not sold on the idea of “imperative programming without any shared mutable state at all”. Maybe I just can’t accurately imagine what that would look like in practice.
Neither.
for tasks that are not inherently unsuited to Rust’s current state
Curious where you draw the line on this.
This is the single “deepest” lesson that I feel like I’ve learned about Rust so far. Lifetimes, stumbled upon while trying to avoid (runtime) garbage collection, are in fact a more general tool for delimiting behavior/causality in programs.
Interesting you use the word “causality” there … do you have anything in particular in mind or are you generally thinking about trying to nail down what the cause of a bug may be?
I liked the phrase from the article (which you quote): you never need to worry about “spooky action at a distance.” (emphasis mine).
for me this mostly comes down to the state of the ecosystem (game dev with godot, websites in js are 2 cases where I’m not really interested in using rust)
but for example when I want to just solve a problem and the input size won’t cause a naive approach to run very slow, I’ll probably grab python instead
or if the solution is something hyper dynamic (a la dynamic programming), it would probably be simpler in ocaml or haskell or f# - ie something more “truly” immutable so that you don’t have to worry about data lifetimes or manual memory management (and it’s generally very cheap and elegant to push & pop from stacks and queues in such languages)
re: causality and “spooky action at a difference”
It’s more:
mutable vs immutable references mean any mutable access must happen before or after all other accesses [to the same data]
any access to a moved value must happen before the move itself
So ownership effectively imposes a certain causal order on your code, that emerges from which behavior uses/accesses which data. In many aspects it’s way too hazy to act as a “proper” causal order, but I often find it easier to write code that passes the borrow checker on the first try when I try to organize my code according to this notion.
I would almost describe my mental image as if there were compiler-enforced RWLocks on all mutable references, and as if all moves are somehow telling the os to change which virtual memory address is mapped onto the (moved) data (without actually copying the data into a different part of memory).
I’d kinda developed the same attitude but never really thought about it in terms of “causality” as you put it. Instead I had more of a “clean code” or “efficiency” framing, but I like yours much better.
This is the single “deepest” lesson that I feel like I’ve learned about Rust so far. Lifetimes, stumbled upon while trying to avoid (runtime) garbage collection, are in fact a more general tool for delimiting behavior/causality in programs.
Similarly, this aligns with my current opinion of rust vs other programming languages for tasks that are not inherently unsuited to Rust’s current state.
I’m not sold on the idea of “imperative programming without any shared mutable state at all”. Maybe I just can’t accurately imagine what that would look like in practice.
Neither.
Curious where you draw the line on this.
Interesting you use the word “causality” there … do you have anything in particular in mind or are you generally thinking about trying to nail down what the cause of a bug may be? I liked the phrase from the article (which you quote): you never need to worry about “spooky action at a distance.” (emphasis mine).
for me this mostly comes down to the state of the ecosystem (game dev with godot, websites in js are 2 cases where I’m not really interested in using rust) but for example when I want to just solve a problem and the input size won’t cause a naive approach to run very slow, I’ll probably grab python instead or if the solution is something hyper dynamic (a la dynamic programming), it would probably be simpler in ocaml or haskell or f# - ie something more “truly” immutable so that you don’t have to worry about data lifetimes or manual memory management (and it’s generally very cheap and elegant to push & pop from stacks and queues in such languages)
re: causality and “spooky action at a difference”
It’s more:
mutable vs immutable references mean any mutable access must happen before or after all other accesses [to the same data]
any access to a moved value must happen before the move itself
So ownership effectively imposes a certain causal order on your code, that emerges from which behavior uses/accesses which data. In many aspects it’s way too hazy to act as a “proper” causal order, but I often find it easier to write code that passes the borrow checker on the first try when I try to organize my code according to this notion.
I would almost describe my mental image as if there were compiler-enforced RWLocks on all mutable references, and as if all moves are somehow telling the os to change which virtual memory address is mapped onto the (moved) data (without actually copying the data into a different part of memory).
Yea nice.
I’d kinda developed the same attitude but never really thought about it in terms of “causality” as you put it. Instead I had more of a “clean code” or “efficiency” framing, but I like yours much better.