Rust: An Introduction

by Ferris the Crab Todd Smith
Rust Solution Architect
Xebia Functional

Where is Rust used?

Backend
Web
Mobile
Embedded
GUI
Games

Noteworthy features of Rust:

Imperative execution

Immutability by default
Algebraic data types
Higher-order functions
Type deduction (Hindley-Milner)
Traits (i.e., type classes)
Pattern matching

Top-tier performance
Type safety
Memory safety
Metaprogramming (macros, auto-derive)
No garbage collector!

Timeline of Rust:

2006: Created by Graydon Hoare at Mozilla
2009: Adopted officially at Mozilla
2015: First stable release
2022: Linux kernel, baby!
2023: Xebia Functional opens Rust service line

Graydon Hoare created Rust as a personal project in 2006 while working at Mozilla.
→
Mozilla officially adopted the project in 2009, but
→
the first stable release wasn't until May 2015. Since its release, grassroots enthusiasm has brought it to
Amazon, Meta, Alphabet, Microsoft, and tons of others.
→
Linus even welcomed it into the kernel in December 2022! But the adoption of programming languages is slow,
yo, so it's only recently that Rust started spreading like wildfire.
→
Now that wildfire has spread to Xebia Functional.
{suspend}
{focus on presenter}
For the next 30 minutes, that wildfire looks like this guy, Todd Smith, the new Rust Solution Architect, laying down some Rust basics, so thanks for joining me today. Without further ado, let's see what Rust brings to table.
{resume}
→

MEMORY SAFETY

(in C 😖)


extern /*@only@*/ int* glob;

/*@only@*/ int* f (
	/*@only@*/ int* x,
	int* y,
	int* z
) /*@globals glob@*/
{
	int* m = (int*) malloc(sizeof(int));
	glob = y;
	free(x);
	*m = *x;
	return z;
}

Splint

							
extern /*@only@*/ int* glob;

/*@only@*/ int* f (
	/*@only@*/ int* x,
	int* y,
	int* z
) /*@globals glob@*/
{
	int* m = (int*) malloc(sizeof(int));
	glob = y;
	free(x);
	*m = *x;
	return z;
}

							
> splint only.c
only.c:10: Only storage glob (type int *) not released
	before assignment: glob = y
only.c:1: Storage glob becomes only
only.c:11: Implicitly temp storage y assigned to only:
	glob = y
only.c:12: Dereference of possibly null pointer m: *m
only.c:9: Storage m may become null
only.c:12: Variable x used after being released
only.c:11: Storage x released
only.c:13: Implicitly temp storage z returned as only: z
only.c:13: Fresh storage m not released before return
only.c:9: Fresh storage m allocated

Splint

By Mbzt - Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=59794940

Hammurabi the Lawgiver

Hammurabi Ferris the Lawgiver

Ownership: The obligation to destroy a value when it goes out of scope.


struct Wrapped<T>(
	T // Owner of some `T`
);

enum Either<A, B> {
	A(A), // Owner of some `A`
	B(B), // Owner of some `B`
}

fn main() {
	let i = 5;            // Owner of `5`
	let w = Wrapped(i);   // Owner of `Wrapped(5)`; `i` still lives
	let a = Either::A(w); // Owner of `Either::A`; `w` destroyed by move
	let _x = f(a);        // Owner of some `Either`; `a` destroyed by move
} // `_x` destroyed by end of block

fn f<A>(
	e: Either<Wrapped<A>, Wrapped<A>>   // Owner of some `Either`
) -> Either<Wrapped<A>, Wrapped<A>> { // Returns ownership of some `Either`
	match e {
		Either::A(a) => // `a` is owner of `Wrapped`; `e` destroyed by move
			Either::B(a), // Temporary is owner of `Either::B`
		Either::B(b) => // `a` is owner of `Wrapped`; `e` destroyed by move
			Either::A(b)  // Temporary is owner of `Either::A`
	} // Return ownership of some `Either`
}

Ownership

I know that was so 2 minutes ago, but remember how I said that Rust doesn't need a garbage collector? Instead, the Rust compiler has a borrow checker, a built-in static analyzer that tracks ownership of values. The borrow checker ensures that Rust always knows when to destroy an object. In the vast majority of cases, the borrow checker can statically determine where to insert the destructor call; in the few cases where it can't, the borrow checker can defer ownership tracking until runtime. There's no escaping the borrow checker, and that's a good thing!
Ownership always accompanies introduction of a value. In other words, when code mentions a literal or instantiates a struct or enum, then some variable, formal parameter, field, or temporary becomes the owner of the new value. And the owner is responsible for the value's eventual destruction, when the owner goes out of scope.
But the owner can also delegate that responsibility, by assigning the value to another variable or field or by giving ownership to another function or method. Whenever you see a punctuation-free type annotation on a formal parameter of a function or method signature, it means that the formal parameter assumes ownership of the passed value. After giving the value away, the owner becomes defunct — it hasn't technically gone out of scope, but the compiler will signal an error if you mention it again.
For simple values, like booleans and numbers, the compiler makes a copy, and the result is two owned values — one associated with the original binding, one with the new binding.
For more complex values, passing the value transfers ownership to the new binding. After the transfer, you can't use the original binding anymore — no takebacks!
→

							
#[derive(Copy)] // Instances will be copied rather than moved
struct Point3D {
	x: f64,
	y: f64,
	z: f64
}

Deriving the Copy trait


struct Wrapped<T>(
	T // Owner of some `T`
);

enum Either<A, B> {
	A(A), // Owner of some `A`
	B(B), // Owner of some `B`
}

fn main() {
	let i = 5;            // Owner of `5`
	let w = Wrapped(i);   // Owner of `Wrapped(5)`; `i` still lives
	let a = Either::A(w); // Owner of `Either::A`; `w` destroyed by move
	let _x = f(a);        // Owner of some `Either`; `a` destroyed by move
} // `_x` destroyed by end of block

fn f<A>(
	e: Either<Wrapped<A>, Wrapped<A>>   // Owner of some `Either`
) -> Either<Wrapped<A>, Wrapped<A>> { // Returns ownership of some `Either`
	match e {
		Either::A(a) => // `a` is owner of `Wrapped`; `e` destroyed by move
			Either::B(a), // Temporary is owner of `Either::B`
		Either::B(b) => // `a` is owner of `Wrapped`; `e` destroyed by move
			Either::A(b)  // Temporary is owner of `Either::A`
	} // Return ownership of some `Either`
}

Ownership


int* x = (int*) malloc(sizeof(int)); // Allocate
free(x);                             // Single free - good
free(x);                             // Double free - bad

C loves double free — no error 🤦


let x = SomeStruct::default(); // Allocate
drop(x);                       // Single free - good
drop(x);                       // Double free - forbidden!

➜ cargo build
   Compiling double-free v0.1.0 (/double-free)
error[E0382]: use of moved value: `x`
 --> double-free/src/main.rs:4:10
  |
2 |     let x = SomeStruct::default();
  |         - move occurs because `x` has type `SomeStruct`, which does not implement the `Copy` trait
3 |     drop(x);
  |          - value moved here
4 |     drop(x);
  |          ^ value used here after move

For more information about this error, try `rustc --explain E0382`.
error: could not compile `double-free` (bin "double-free") due to previous error

Rust hates double free — compiler error 🙌

Borrow: Access to a value without the obligation to destroy that value when it goes out of scope.


struct Wrapped<T>(
	T // Owner of some `T`
);

enum Either<'a, 'b, A, B> {
	A(&'a A), // Immutable borrow of some `A` with lifetime 'a
	B(&'b B), // Immutable borrow of some `B` with lifetime 'b
}

fn main() {
	let w = Wrapped(5);        // Owner of `Wrapped(5)`
	let mut a = Either::A(&w); // Mutable owner of `Either`; `w` immutably borrowed
	f(&mut a);                 // `a` mutably borrowed, updated by call
} // `a` & `w` destroyed by end of block

fn f<'a, A>(
	e: &mut Either<'a, 'a, A, A> // Mutable borrow of some `Either`
) {
	*e = match e {
		Either::A(a) => // `a` owns borrow of `A`
			Either::B(a), // `e` becomes owner of new `Either`; `a` moved
		Either::B(b) => // `a` owns borrow of `A`
			Either::A(b)  // `e` becomes owner of new `Either`; `b` moved
	}
}

Borrowing


struct Wrapped<T>(
	T // Owner of some `T`
);

enum Either<'a, 'b, A, B> {
	A(&'a A), // Immutable borrow of some `A` with lifetime 'a
	B(&'b B), // Immutable borrow of some `B` with lifetime 'b
}

fn main() {
	let w = Wrapped(5);        // Owner of `Wrapped(5)`
	let mut a = Either::A(&w); // Mutable owner of `Either`; `w` immutably borrowed
	f(&mut a);                 // `a` mutably borrowed, updated by call
} // `a` & `w` destroyed by end of block

fn f<'a, A>(
	e: &mut Either<'a, 'a, A, A> // Mutable borrow of some `Either`
) {
	*e = match e {
		Either::A(a) => // `a` owns borrow of `A`
			Either::B(a), // `e` becomes owner of new `Either`; `a` moved
		Either::B(b) => // `a` owns borrow of `A`
			Either::A(b)  // `e` becomes owner of new `Either`; `b` moved
	}
}

Borrowing

Rules of borrowing:

Either there may be one mutable borrow
Or there may be zero or many immutable borrows
References must refer to live values, i.e., no dangling references

Firstly, there can be only one mutable borrower of some referenced value. So long as a mutable borrow exists, no other borrows can exist at all. And while the mutable borrow exists, even the owner cannot modify the underlying value. If you think of this in physical object terms, it makes perfect sense — how can you scribble in the margins of a book that you've lent out to a friend?
→
Secondly, so long as no mutable borrower exists, there can be many immutable borrowers of some referenced value. The physical analogy isn't straightforward here, because I usually can't lend the same book to each of my friends. Something to do with conservation of mass, I don't know. But fortunately, there's a good analogy from concurrent programming: read/write locks!
→
Lastly, references cannot outlive their owners. If they could, then they could become invalid by pointing to freed (and potentially reused) memory. But the borrow checker statically ensures that all borrows occur within the lexical scope of the owner. In other words, borrows have to go out of scope before or simultaneously with the owner. And just like that, Rust prohibits dangling references by construction.
→


	fn owner_dropped_while_borrowed() {
		let outer_borrow: &i32;
		{
			let inner_borrow: &i32;
			let owner: i32 = 10;
			inner_borrow = &owner;
			outer_borrow = inner_borrow;
		}
		println!("heh, heh = {}", outer_borrow);
	}

Borrower, schmorrower

But does it? Does it really? What happens if I do something sneaky, like this? Here, I've nested two scopes. Inside the inner scope is the hapless and doomed owner of the value `10`, as well as the creatively named inner_borrow of owner. But in the outer scope is the villainous outer_borrow, which tries to borrow owner indirectly through the unsuspecting inner_borrow. Since owner goes out of scope on line 8 and outer_borrow survives until line 10, outer_borrow should become a dangling reference after line 8.
→


fn owner_dropped_while_borrowed() {
	let outer_borrow: &i32;
	{
		let inner_borrow: &i32;
		let owner: i32 = 10;
		inner_borrow = &owner;
		outer_borrow = inner_borrow;
	}
	println!("heh, heh = {}", outer_borrow);
}

➜ cargo build
   Compiling rust-presentation-2023-11-09 v0.1.0 (/naive-borrow)
error[E0597]: `owner` does not live long enough
 --> naive-borrow/src/main.rs:6:18
  |
5 |         let owner: i32 = 10;
  |             ----- binding `owner` declared here
6 |         inner_borrow = &owner;
  |                        ^^^^^^ borrowed value does not live long enough
7 |         outer_borrow = inner_borrow;
8 |     }
  |     - `owner` dropped here while still borrowed
9 |     println!("heh, heh = {}", outer_borrow);
  |                               ------------ borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `naive-borrow` (bin "naive-borrow") due to previous error

Curses, foiled again!

Is Rust going to stand for that? Nah, not really. The borrow checker noticed that owner didn't live long enough to accommodate the outer_borrow, so it forbade the assignment outright, even though it tried using inner_borrow as a patsy.
→

									
fn assign_through_borrow(
	a: &mut &i32,
	b: &mut &i32
) {
	*b = *a;
}

fn owner_dropped_while_borrowed() {
	let outer_owner = 10;
	let mut outer_borrow = &outer_owner;
	{
		let inner_owner = 10;
		let mut inner_borrow = &inner_owner;
		assign_through_borrow(
			&mut inner_borrow,
			&mut outer_borrow
		);
	}
	println!("heh, heh = {}", outer_borrow);
}

Borrower, schmorrower

But maybe we can get even more creative, by using an intermediate function call to disguise our perfidy. Here, we've introduced two owners, outer_owner and inner_owner, and initialized matching borrows, outer_borrow and inner_borrow. Nothing suspicious so far. assign_to_borrow looks innocent enough, too — it just does an assignment whose effect is visible in the caller. But the actual call of assign_to_borrow is super sketch — it mutably borrows inner_borrow and outer_borrow so that the callee can make outer_borrow point to inner_owner. Muahaha, dangling reference created! Suck it, Rust!
→

						
fn assign_through_borrow(
	a: &mut &i32,
	b: &mut &i32
) {
	*b = *a;
}

➜ cargo build
   Compiling sneaky-borrow v0.1.0 (/sneaky-borrow)
error: lifetime may not live long enough
 --> sneaky-borrow/src/main.rs:5:2
  |
2 |     a: &mut &i32,
  |             - let's call the lifetime of this reference `'1`
3 |     b: &mut &i32
  |             - let's call the lifetime of this reference `'2`
4 | ) {
5 |     *b = *a;
  |     ^^^^^^^ assignment requires that `'1` must outlive `'2`
  |
help: consider introducing a named lifetime parameter
  |
1 ~ fn assign_through_borrow<'a>(
2 ~     a: &mut &'a i32,
3 ~     b: &mut &'a i32
  |

error: could not compile `sneaky-borrow` (bin "sneaky-borrow") due to previous error

Curses, foiled again!

Wait, what's this? Rust won't compile assign_to_borrow! Curses, foiled again! But how did it know?
There's more to a borrow than its referent. There's also its lifetime. In other words, how long the borrow points to a live owner. In any language, a reference must not outlive its referent's owner, because that's how you get dangling references, yo. But in Rust, the compiler enables — nay, forces — you to get it right. The borrow checker statically tracks the lifetime of every borrow, and it does this by implicitly or explicitly attaching a lifetime through a built-in property. The property is expressed as a generic type parameter of the enclosing context; in this case, the function assign_to_borrow.
Now we can unpack the compiler's error message. The compiler forbade the redirection of b's content to a's content because it assumed that their lifetimes were unrelated. And in a vacuum, what else _could_ it assume? Most assumptions would be wrong in most circumstances, so Rust makes the most general possible assumption, thereby forcing us to clarify our intentions.
→

									
fn annotated_assign_through_borrow<
	'a: 'b,
	'b
>(
	a: &mut &'a i32,
	b: &mut &'b i32,
) {
	*b = *a;
}

fn owner_dropped_while_borrowed() {
	let outer_owner = 10;
	let mut outer_borrow = &outer_owner;
	{
		let inner_owner = 10;
		let mut inner_borrow = &inner_owner;
		annotated_assign_through_borrow(
			&mut inner_borrow,
			&mut outer_borrow
		);
	}
	println!("heh, heh = {}", outer_borrow);
}

Borrower, schmorrower

Okay, let's make one last ditch effort to achieve villainy, because I don't know why. We're going to add two lifetime parameters to assign_to_borrow, one for each formal parameter. We'll name the lifetimes after the formal parameters themselves, out of convenience rather than syntactic necessity, and we're going to use a colon to say that 'a outlives 'b. That guarantees locally that we can perform the assignment.
→

						
fn owner_dropped_while_borrowed() {
	let outer_owner = 10;
	let mut outer_borrow = &outer_owner;
	{
		let inner_owner = 10;
		let mut inner_borrow = &inner_owner;
		annotated_assign_through_borrow(
			&mut inner_borrow,
			&mut outer_borrow
		);
	}
	println!("heh, heh = {}", outer_borrow);
}

➜ cargo build
   Compiling sneaky-borrow-with-lifetime v0.1.0 (/sneaky-borrow-with-lifetime)
error[E0597]: `inner_owner` does not live long enough
  --> sneaky-borrow-with-lifetime/src/main.rs:13:26
   |
12 |         let inner_owner = 10;
   |             ----------- binding `inner_owner` declared here
13 |         let mut inner_borrow = &inner_owner;
   |                                ^^^^^^^^^^^^ borrowed value does not live long enough
...
18 |     }
   |     - `inner_owner` dropped here while still borrowed
19 |     println!("heh, heh = {}", outer_borrow);
   |                               ------------ borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `sneaky-borrow-with-lifetime` (bin "sneaky-borrow-with-lifetime")
due to previous error

Curses, foiled again!

You may already be able to guess why this won't work. And there it is, we're straight back to the original "problem". Now that we've told Rust the relationship between the lifetimes, it throws them right back in our face to defeat our insidious attempt to create a dangling reference. So … yeah. Rust really does prevent dangling references by construction. Pretty sweet, yeah?
But if the story ended here, then it would be an incomplete story. What we've seen is impressive, but it doesn't cover the gamut of memory access patterns. What about heap-resident values? What about shared ownership? What about cycles? More generally, what about situations where it's much harder to decide when a value should be destroyed? Well, Rust provides several smart pointer types that flesh out its memory safety story.
→


// Excerpted from standard library.
pub struct Box<
		// Any type, even if size is statically unknown
    T: ?Sized,
		// To support "placement new"
    A: Allocator = Global
>(Unique<T>, A); // `Unique` means "sole owner"

Box

The simplest is Box, which simply designates a value that lives on the heap. By default, Rust allocates all values on the stack, but Box and other smart pointers maintain their referents on the heap. Box is usually the right choice for types whose instances vary in size. Box is generic over two type parameters: T, which represents the type on the heap; and A, the type of the allocator responsible for managing that heap. Usually you only care about T, but A is available for so-called "placement new" situations, à la C++. In the vast majority of cases where you don't care, you don't have to mention A at all, and Rust will sensibly default it to the same type as the global allocator. There's no special magic here — like C++ and TypeScript and unlike Java, Kotlin, Scala, C#, and others, Rust supports default bindings for generic parameters. A Box is the sole owner of its content, so the content lives exactly as long as the Box does. When the Box goes out of scope, it and its contents are both destroyed.
→

Who owns E?


// Simplified from standard library.
pub struct RcInner<T: ?Sized> {
	// Interiorly mutable strong count
	strong: Cell<usize>,
	// Interiorly mutable weak count (for cycle breaking)
	weak: Cell<usize>,
	// The shared value
	value: T
}

pub struct Rc<T: ?Sized> {
	// The shared value, plus reference counts
	inner: Box<RcInner<T>>
}

Simplified Rc

Rc to the rescue. Rc stands for reference counter. Rc is really just a thin wrapper for a private kind of Box that places both the referent and the reference counter on the heap. This reference counter is incremented whenever the Rc is cloned, and decremented whenever the Rc goes out of scope. When the reference count goes to zero, the referent is destroyed. And because no Rc is outstanding, by definition, there are no dangling references to the defunct referent.
→


pub struct GraphNode<T> {
	// The payload
	value: T,
	// The vector of successors
	successors: Vec<Rc<GraphNode<T>>>
}

Shared Ownership with Rc

Achievement unlocked: shared ownership!
So, what about mutating the referent of an Rc? Well, you can't. The private box inside is the real single owner of the shared data, and each Rc behaves like an immutable borrow of the box. If it didn't, then you could trivially violate the borrow checker's rule that each value can have at most one live mutable reference, which can lead to memory unsafety even in a single-threaded program.
So, does that mean that we can use Rc with multiple threads? Not quite, but we can use its concurrent cousin,
→


// Simplified from standard library.
pub struct ArcInner<T: ?Sized> {
	// Atomically mutable strong count
	strong: atomic::AtomicUsize,
	// Atomically mutable weak count (for cycle breaking)
	weak: atomic::AtomicUsize,
	// The shared value
	value: T
}

pub struct Arc<T: ?Sized> {
	// The shared value, plus reference counts
	inner: Box<ArcInner<T>>
}

Simplified Arc

Arc, which stands for atomic reference counter. Arc leverages special compiler intrinsics to ensure memory coherency in the presence of concurrent access, so it entails a bit more cost than Rc. This is one of several situations where Rust offers you a choice of abstractions, enabling you to right-size your choice based on your actual use case.
{wait 3s}
→

						
fn main() {
	let shared: Arc<i32> = Arc::new(10);
	let copy = Arc::clone(&shared);
	let forked = spawn(move || {
		println!("first thread: {}", *copy);
	});
	forked.join().unwrap();
	println!("main thread: {}", *shared);
}

Share immutable data with Arc

Armed with an Arc, you can now share a value between multiple threads and still be confident that it will be destroyed exactly once, as early as possible, without leaving a dangling reference behind. You still can't mutate the shared value, but we're getting closer. There are alternatives to concurrent data access patterns, of course — right, functional programmers? — and Rust enables numerous strategies, but dang it, sometimes it's convenient to mutate shared data rather than, I don't know, pass copies between threads.
→

						
fn main() {
	let shared: Arc<Mutex<i32>> = Arc::new(Mutex::new(0));
	let join_handles: Vec<JoinHandle<()>> = (1..=10)
		.map(|_| { // Don't care about the subscript, only running 10 times
			let copy = Arc::clone(&shared);
			spawn(move || {
				let mut guarded_value: MutexGuard<i32> = copy.lock().unwrap();
				*guarded_value += 1;
			})
		})
		.collect();  // Iterators are lazy, so must collect
	// Wait for all threads to complete.
	join_handles.into_iter().for_each(|h| h.join().unwrap());
	println!("{}", *shared.lock().unwrap()); // Prints "10\n"
}

Share mutable data with Arc<Mutex>

Enter Mutex, the canonical mutual exclusion device from imperative programming. You can use the lock and try_lock methods to obtain a MutexGuard. Once you have a MutexGuard, it acts as an exclusive mutable reference to the protected value, so any code dynamically reachable from the lexical scope of the MutexGuard can access and mutate the protected value. When the MutexGuard goes out of scope, its destruction releases the exclusive hold, giving some other thread a turn to enter its own critical section. This is a textbook example of RAII — Resource Acquisition Is Initialization.
Now let's put it all together, literally. Start with our data, which might be of any type, so let's call it T. We need to ensure exclusive access in order to satisfy Rust's rules regarding mutation, so we wrap a Mutex around it to obtain Mutex<T>. And we want shared ownership, so we wrap an Arc around that to obtain an Arc<Mutex<T>>. We can clone the Arc to ratchet up the reference count, and use closures to transfer ownership of the copied smart pointer to another thread. When the last Arc goes out of scope, the Mutex and its protected value are both destroyed.
→

									
fn main() {
	let shared: Rc<i32> = Rc::new(10);
	let copy = Rc::clone(&shared);
	let forked = spawn(move ||
		{
			println!("first thread: {}", *copy);
		}
	);
	forked.join().unwrap();
	println!("main thread: {}", *shared);
}

Borrower, schmorrower

You may be wondering what keeps me from using an Rc with multiple threads, other than a craftsman's desire not to write bad code that breaks a product at runtime. Let's put the supervillain mustache back on for a moment. Surely, you can use an Rc instead of an Arc to break Rust at runtime, right? Obviously, it would be asking way too much to think that Rust could statically forbid data races, right? So much for Rust's vaunted memory safety guarantees, muahaha!
→

						
fn main() {
	let shared: Rc<i32> = Rc::new(10);
	let copy = Rc::clone(&shared);
	let forked = spawn(move ||
		{
			println!("first thread: {}", *copy);
		}
	);
	forked.join().unwrap();
	println!("main thread: {}", *shared);
}

➜ cargo build
   Compiling concurrent-rc v0.1.0 (/concurrent-rc)
error[E0277]: `Rc<i32>` cannot be sent between threads safely
   -->; concurrent-rc/src/main.rs:7:21
    |
7   |       let forked = spawn(move ||
    |                    ----- ^------
    |                    |     |
    |  __________________|_____within this `[closure@concurrent-rc/src/main.rs:7:21: 7:28]`
    | |                  |
    | |                  required by a bound introduced by this call
8   | |         {
9   | |             println!("first thread: {}", *copy);
10  | |         }
    | |_________^ `Rc<i32>` cannot be sent between threads safely
    |
    = help: within `[closure@concurrent-rc/src/main.rs:7:21: 7:28]`, the trait `Send` is not implemented for `Rc<i32>`
note: required because it's used within this closure
   --> concurrent-rc/src/main.rs:7:21
    |
7   |     let forked = spawn(move ||
    |                        ^^^^^^^
note: required by a bound in `spawn`
   --> /lib/rustlib/src/rust/library/std/src/thread/mod.rs:680:8
    |
680 |     F: Send + 'static,
    |        ^^^^ required by this bound in `spawn`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `concurrent-rc` (bin "concurrent-rc") due to previous error

Curses, foiled again!

Huh, looks like the fuzz caught us again. "Rc<i32> cannot be sent between threads safely," because "the trait Send is not implemented for Rc<i32>." Other than, "curses, foiled again," what does this mean? It all comes down to how Rust knows that it's legal to transfer ownership of an Arc to another thread but not an Rc.
→

Traits in Rust:

Like interfaces in Java, Kotlin
Like traits in Scala
Like type classes in Haskell
May prescribe one or more methods
May provide default implementations of methods
May not specify state

Traits in Rust are analogous to
→
interfaces in Java and Kotlin, traits in Scala, and type classes in Haskell.
→
A trait specifies a behavioral contract that any conformant types have to implement. The contract can include default implementations for one or more methods,
→
but cannot directly specify any state. When instantiating a trait for a concrete type, the compiler copies down any default methods that were not overridden, complements them with overrides and explicit implementations of abstract methods, and verifies that all behavior is covered. This is all well and good, and not too interesting. What's interesting in this regard is Rust's handful of magical marker traits. Markers statically ascribe interesting properties to types, and thus inform the compiler's semantic validation and code generation.
→

Send: Auto trait that denotes types that can be moved across thread boundaries
(because they are not subject to data races)

Let's return to the concrete problem that sent us down the trait rabbit hole, the Send trait.
→
The Send trait does not specify any methods, but instead specifies that conformant types may be transferred
→
safely across thread boundaries.
→

						
fn main() {
	let shared: Rc<i32> = Rc::new(10);
	let copy = Rc::clone(&shared);
	let forked = spawn(move ||
		{
			println!("first thread: {}", *copy);
		}
	);
	forked.join().unwrap();
	println!("main thread: {}", *shared);
}

➜ cargo build
   Compiling concurrent-rc v0.1.0 (/concurrent-rc)
error[E0277]: `Rc<i32>` cannot be sent between threads safely
   -->; concurrent-rc/src/main.rs:7:21
    |
7   |       let forked = spawn(move ||
    |                    ----- ^------
    |                    |     |
    |  __________________|_____within this `[closure@concurrent-rc/src/main.rs:7:21: 7:28]`
    | |                  |
    | |                  required by a bound introduced by this call
8   | |         {
9   | |             println!("first thread: {}", *copy);
10  | |         }
    | |_________^ `Rc<i32>` cannot be sent between threads safely
    |
    = help: within `[closure@concurrent-rc/src/main.rs:7:21: 7:28]`, the trait `Send` is not implemented for `Rc<i32>`
note: required because it's used within this closure
   --> concurrent-rc/src/main.rs:7:21
    |
7   |     let forked = spawn(move ||
    |                        ^^^^^^^
note: required by a bound in `spawn`
   --> /lib/rustlib/src/rust/library/std/src/thread/mod.rs:680:8
    |
680 |     F: Send + 'static,
    |        ^^^^ required by this bound in `spawn`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `concurrent-rc` (bin "concurrent-rc") due to previous error

🤔

Rc does not implement Send, so the compiler forbids it from being captured by the closure passed to spawn. But Arc does implement Send, so Rust allows it.
{wait 3s}
→

									
fn main() {
	let shared: Arc<Rc<i32>> =
		Arc::new(Rc::new(10));
	let copy = Arc::clone(&shared);
	let forked = spawn(move ||
		{
			println!("first thread: {}", **copy);
		}
	);
	forked.join().unwrap();
	println!("main thread: {}", **shared);
}

Borrower, schmorrower

Okay, let's try one more technique to cheat the compiler. Maybe we can embed an Rc within an Arc in order to bypass Rust's borrow checker.
{wait 7s}
→

						
fn main() {
	let shared: Arc<Rc<i32>> =
		Arc::new(Rc::new(10));
	let copy = Arc::clone(&shared);
	let forked = spawn(move ||
		{
			println!("first thread: {}", **copy);
		}
	);
	forked.join().unwrap();
	println!("main thread: {}", **shared);
}

➜ cargo build
   Compiling concurrent-rc-in-arc v0.1.0 (/concurrent-rc-in-arc)
error[E0277]: `Rc<i32>` cannot be shared between threads safely
   --> concurrent-rc-in-arc/src/main.rs:8:21
    |
8   |       let forked = spawn(move ||
    |  __________________-----_^
    | |                  |
    | |                  required by a bound introduced by this call
9   | |         {
10  | |             println!("first thread: {}", **copy);
11  | |         }
    | |_________^ `Rc<i32>` cannot be shared between threads safely
    |
    = help: the trait `Sync` is not implemented for `Rc<i32>`
    = note: required for `Arc<Rc<i32>>` to implement `Send`
note: required because it's used within this closure
   --> concurrent-rc-in-arc/src/main.rs:8:21
    |
8   |     let forked = spawn(move ||
    |                        ^^^^^^^
note: required by a bound in `spawn`
   --> /lib/rustlib/src/rust/library/std/src/thread/mod.rs:680:8
    |
680 |     F: Send + 'static,
    |        ^^^^ required by this bound in `spawn`
    …

For more information about this error, try `rustc --explain E0277`.
error: could not compile `concurrent-rc-in-arc` (bin "concurrent-rc-in-arc") due to previous error

Curses, foiled again!

Sync: Auto trait that denotes types that can be shared across thread boundaries
(because they are not subject to data races)

Sync is another marker trait.
→
When a type implements Sync, its instances are permitted to be
→
shared between threads.
→

Rules for Send and Sync

(which I am definitely not talking about in this presentation)

A type is Send iff it is safe to move to another thread.
A type is Sync iff it is safe to share with other threads.
T is Sync iff &T is Send.
A compound type that is composed entirely of Send or Sync types, then it is Send or Sync.
Raw pointers (*const T and *mut T are neither Send nor Sync.
Cell, RefCell, and UnsafeCell are not Sync.
Rc is not Send or Sync! 😀

Send and Sync are both _auto traits_: they are automatically implemented by the compiler whenever they apply, so they automatically apply to most immutable primitive data — booleans, integers, and floats. For composite types, like structs and enums, Rust looks at the fields and variants of the type to decide whether the type itself is Send or Sync.
→
The rules are a bit complex, so I won't go into them here. But you can wrap types that don't implement Send or Sync in synchronized types like Mutex or RwLock, which do implement Send and Sync, thereby allowing transfer or sharing with other threads.
But Rc<T> doesn't implement Sync, so Arc<Rc<T>> also doesn't implement Sync. Therefore, it's impossible to share an Arc<Rc<T>> with another thread. Once again, Rust has statically ensured memory safety.
→

MEMORY SAFETY
`==`
THREAD SAFETY

(in Rust 🦀 !)

Now that we're talking about concurrent programming, though, a new observation emerges. Memory safety is thread safety.
→
Rust ensures memory safety statically, and because it includes deep primitive support for ensuring memory safety across thread boundaries, via Send, Sync, and other mechanisms, it also statically protects against data races.
Unless you resort to really weird patterns with unsafe code or foreign function calls, Rust guarantees that any memory safe program is also free of data races. This is a unique selling point for Rust, folks. As of Q4 2023, no other programming language can claim to achieve this effect in quite this way. Rust's deep memory safety enables what the official Rust book aptly likes to call fearless concurrency.
I focused this talk around Rust's memory model, because in many ways, this _is_ the real novelty. Rust has a lot of cool features — zero-cost abstractions, immutability by default, algebraic data types, pattern matching, higher-order functions, type deduction through unification based on a variant of the Hindley-Milner algorithm, traits with associated type parameters, object-oriented programming through trait objects, interior mutability, metaprogramming through macros, asynchronous I/O — but its deeply reasoned and superbly architected memory model is the heart and soul of Rust. It secures Rust's place in the pantheon of systems programming languages: safe, fast, supreme.
→

Official Rust resources:

Community Rust resources:

Internal Xebia Functional Rust resources:

Please request access if you don't have it!

MEMORY SAFETY

MEMORY SAFETY == THREAD SAFETY

MEMORY SAFETY
`==`
THREAD SAFETY