Rust Lifetimes

2019-09-05

Roland Brand

Sources

We're already used to memory safety (as long as we're talking single threaded)
These languages almost completely hide memory management away from the developer
- easy to use
- high runtime overhead
- hard to optimize
We're at the slow end of the
"Garbage Collector Gap"

copy for primitive values is familiar
for references to the heap we are usually more familiar with clone instead of move

lifetimes make sure we cannot have references to moved values at any time

Rust aims to avoid the "sea of objects" which typically arises with (undisciplined) OOP

at the end of scope ( } ) all values owned by the scope are dropped if they haven't been moved yet
return moves the value to the parent stack frame
no garbage collection! Memory is freed immediately

Within the same lifetime:
- You can borrow either
  - one mutable reference
  - many immutable references

primitive assignment

assignment by reference (object)

...this is what we are used to (behind the scenes)

a = b

doSomething(b)

Copy trait

Move trait (b becomes unusable)

borrowing

Cell / RefCell

If you need behavior from familiar OOP patterns, you can use Rc and RefCell.
However, this is very verbose and you might be using Rust wrong
How about
- (idempotent) functional programming with little state, reactive patterns, pattern matching with match and algebraic enum types
- Use crates for complex data structures
- Use other languages for the high level smalltalk, and Rust for powerful libraries