Sorting — almost never your problem

The first problem any programmer learns, and one of the very few where the standard library is always the right answer.

1. 01
   sort_unstable_by_key is the right default — faster than sort for most workloads, allocates nothing, and is what std ships. Reach for rayon::par_sort_unstable_by when the slice is large enough that the parallel split pays for itself.

   use rayon::slice::ParallelSliceMut;
   
   struct Order { id: u64, price_cents: u64, placed_at: u64 }
   
   fn newest_first(orders: &mut [Order]) {
       orders.sort_unstable_by_key(|o| std::cmp::Reverse(o.placed_at));
   }
   
   fn newest_first_parallel(orders: &mut [Order]) {
       orders.par_sort_unstable_by_key(|o| std::cmp::Reverse(o.placed_at));
   }

2. 02
   "Unstable" here is a property of the sorting algorithm, not Rust's unsafe keyword. A stable sort preserves the original relative order of equal elements; an unstable sort may reorder them. Rust's sort() is stable (a Timsort variant) and allocates scratch space on the heap. sort_unstable() uses pdqsort (a tuned quicksort) — faster, allocates nothing, but two Orders with the same placed_at might come out in either order. For newest-first ranking, nothing in the schema cares which of two same-timestamp orders appears first, so sort_unstable is the right default. Reach for plain sort only when you actually rely on equal-key stability — for example, when an earlier sort already established a secondary order you want to preserve.

   // "unstable" here = the sorting algorithm may reorder equal elements.
   // It has nothing to do with Rust's `unsafe` keyword.
   
   let mut orders = vec![
       Order { id: 1, placed_at: 100, /* .. */ },   // input order: 1 before 2
       Order { id: 2, placed_at: 100, /* .. */ },
       Order { id: 3, placed_at:  50, /* .. */ },
   ];
   
   orders.sort_by_key(|o| o.placed_at);
   // → ids: [3, 1, 2]   stable: id 1 stays before id 2 because they tie
   
   orders.sort_unstable_by_key(|o| o.placed_at);
   // → ids: [3, 1, 2] or [3, 2, 1]   either is allowed — they tie
   
   // Rule of thumb:
   //   sort()           ← stable, allocates, slightly slower
   //   sort_unstable()  ← unstable, no allocation, fastest default

3. 03
   Separately, safe vs unsafe Rust is a different axis entirely. All of the code on this page is safe Rust — the compiler proves at compile time that there are no use-after-free, no out-of-bounds indexing, no data races. The unsafe keyword exists for the small minority of cases where you need to opt out of those checks (dereferencing raw pointers, calling C functions, building a new data structure whose invariants the compiler cannot see). An unsafe block does not turn off the type system — it adds five specific superpowers, and the burden is on you to prove they are used correctly. Nothing in this book uses unsafe. The whole point of the language is that high-performance code (like sort_unstable or rayon's parallel sort) is achievable without it.

   // Safe Rust — what every example in this book uses.
   // Compiler guarantees: no use-after-free, no data races,
   // no out-of-bounds indexing, no null-pointer dereferences.
   fn ok(orders: &mut [Order]) {
       orders.sort_unstable_by_key(|o| o.placed_at);
   }
   
   // Unsafe Rust — used inside std and a few low-level crates.
   // You write `unsafe` to take responsibility for invariants
   // the compiler cannot check.  Five things become legal:
   //   1. dereference a raw pointer
   //   2. call an unsafe function
   //   3. access a mutable static
   //   4. implement an unsafe trait
   //   5. access fields of a union
   fn raw_example(ptr: *const u32) -> u32 {
       unsafe { *ptr }   // YOU promise ptr is valid and aligned
   }
   
   // "unstable sort" and "unsafe Rust" sound related and are not.
   // sort_unstable is 100% safe.