When `unsafe` and FFI Are Actually Necessary (and the Many Times They Are Not)

21 min read

The rest of this section taught you how to write unsafe and call into C. This page is about a harder, more valuable skill: deciding whether you should at all. For the overwhelming majority of application code — including code that feels like it “obviously needs” a native escape hatch — the answer is no, and reaching for unsafe or the Foreign Function Interface (FFI) trades away the exact guarantee you came to Rust for.

Quick Overview

Coming from TypeScript, you have an instinct that “going low-level” means abandoning safety — in JavaScript there is no low-level to go to, so the very idea feels exotic and powerful. In Rust, unsafe is rarely the tool for performance, sharing, or cleverness; it is a tool for a small, specific set of jobs the type system genuinely cannot express: talking to C/C++, talking to hardware or the OS at the syscall level, and building a handful of foundational data structures whose internal invariants the borrow checker cannot see.

The practical rule for a working developer is this: default to safe Rust, and treat every unsafe block or FFI boundary as a cost you must justify — a piece of code where you, not the compiler, are now responsible for memory safety, and where a mistake is undefined behavior (UB) rather than a catchable exception. Most of the time the justified reason is “I must call code written in another language,” not “I want this to be faster” or “the borrow checker is in my way.” This page gives you a decision procedure and a set of safe alternatives so you can tell the difference.

TypeScript/JavaScript Example

In Node.js, the equivalent decision is “should I drop down to a native addon (a .node binary built from C++/Rust) instead of staying in pure JavaScript?” TypeScript developers face this exact fork, and the reasoning maps closely onto Rust’s unsafe/FFI decision.

1
// checksum.ts — a CPU-bound task someone might think "needs a native addon."
2

3
// Option A: pure JavaScript. Boring, portable, no build step, no segfaults.
4
function crc32(data: Uint8Array): number {
5
  let crc = 0xffffffff;
6
  for (const byte of data) {
7
    crc ^= byte;
8
    for (let i = 0; i < 8; i++) {
9
      crc = (crc >>> 1) ^ (0xedb88320 & -(crc & 1));
10
    }
11
  }
12
  return (crc ^ 0xffffffff) >>> 0;
13
}
14

15
// Option B: a native addon (e.g. via `node-gyp` + C++, or a prebuilt .node file).
16
//   import { crc32 } from "fast-crc32-native";   // a compiled binary
17
// Faster on huge inputs — but now you own:
18
//   - a C/C++ toolchain in CI and on every contributor's machine
19
//   - prebuilt binaries per OS/arch (or a compile step at install time)
20
//   - the risk that a bug in the native code crashes the whole Node process
21
//     (a segfault, not a try/catch-able Error)
22

23
const payload = new TextEncoder().encode("the quick brown fox");
24
console.log("0x" + crc32(payload).toString(16).padStart(8, "0"));
25
// 0x91c102ca

Run with node --experimental-strip-types checksum.ts and it prints 0x91c102ca. The lesson every senior Node developer eventually internalizes: a native addon is a liability you take on for a measured win, not a default. The same calculus — only sharper, because the failure mode is UB instead of a process crash you can at least observe — governs unsafe and FFI in Rust.

Rust Equivalent

Here is the punchline first: that same CRC32, in Rust, needs zero unsafe and zero FFI, because a battle-tested, pure-safe-Rust crate already exists. The first move when you think “I need to call C” is almost always “search crates.io.”

1
// src/main.rs  —  Cargo.toml: crc32fast = "1.5"
2
use crc32fast::Hasher;
3

4
// "We already have a C library for CRC32, let's FFI to it."
5
// Before writing a line of unsafe, check crates.io: a battle-tested,
6
// pure-safe-Rust crate almost always already exists.
7
fn checksum(data: &[u8]) -> u32 {
8
    let mut hasher = Hasher::new();
9
    hasher.update(data);
10
    hasher.finalize()
11
}
12

13
fn main() {
14
    let payload = b"the quick brown fox";
15
    println!("crc32 = {:#010x}", checksum(payload));
16
}

1
$ cargo run
2
crc32 = 0x91c102ca

crc32fast (current version 1.5.0) exposes a fully safe API and uses CPU acceleration (SIMD) where available. Its small unsafe core — the SIMD hot path — is written, audited, and tested once inside the crate, so your code stays 100% safe. You got the speed of a native implementation, the matching checksum (0x91c102ca, identical to the Node output above), and you kept every memory-safety guarantee. That is the pattern: the safe Rust ecosystem has usually already paid the unsafe cost for you, once, behind a reviewed boundary — so you don’t have to.

Tip: When you catch yourself reaching for FFI or unsafe, run cargo search <thing> (or browse lib.rs) first. The answer to “is there a safe crate for this?” is yes far more often than newcomers expect.

Detailed Explanation

To decide well, separate the legitimate reasons for unsafe/FFI from the seductive but usually wrong ones.

The genuinely necessary cases

There are only a few, and they share a property: the requirement comes from outside Rust’s type system, so no amount of safe-Rust cleverness can satisfy it.

Calling code written in another language. You must use an existing C/C++ library (OpenSSL, SQLite, a vendor SDK, a game engine, an OS API not yet wrapped). This is FFI’s reason to exist. The unsafe is unavoidable at the boundary, because the Rust compiler cannot see across the language barrier to verify the foreign code keeps its promises. Covered in calling-c.md and bindgen.md.
Being called by another language. You are shipping a Rust library that JavaScript, Python, or C must consume — for example a Node.js native addon. The extern "C" / #[no_mangle] boundary is necessarily unsafe. See ffi-basics.md, napi.md, and neon.md.
Foundational data structures the borrow checker cannot express. A doubly linked list, an arena allocator, a lock-free queue, a custom smart pointer — these have aliasing patterns (two pointers to one node, self-references) that are sound but that the borrow checker conservatively rejects. The standard library, Vec, Box, Rc, and crates like crossbeam and slotmap are exactly this: a thin audited unsafe core under a safe API. The skill of writing that core is safety-abstractions.md. The skill on this page is recognizing that you almost never need to write it yourself, because it already exists.
Hardware, kernels, embedded, and syscalls. Memory-mapped I/O, custom allocators, no_std firmware, raw syscalls — places where there is no OS or runtime to provide safety, so you provide it. Out of scope for application developers; see Section 26: Systems Programming.
A measured, hot performance gain that safe Rust cannot reach. Real, but rare, and last on the list deliberately. This means: you profiled, you found a specific bottleneck, the bounds check or the safe abstraction is provably the cost, and an unsafe version is meaningfully faster. The discipline of measuring before optimizing belongs to Section 21: Performance.

The seductive-but-usually-wrong cases

These are the ones that catch TypeScript developers, because the instincts that serve you in JavaScript point the wrong way here.

“It’ll be faster.” Usually false. Safe Rust is already a systems language: no garbage collector, no boxing-by-default, monomorphized generics, and an optimizer (LLVM) that aggressively elides bounds checks it can prove are redundant and autovectorizes tight loops into SIMD. The safe version is typically within noise of the unsafe one — and sometimes faster, because unsafe can inhibit optimizations the compiler would otherwise make under safe aliasing rules.
“The borrow checker won’t let me share this.” This is the big one. In JavaScript every object is a shared, mutable, garbage-collected reference, so “two things point at one thing” is your default mental model. Rust forbids that by default — but it gives you safe tools for it: Rc/Arc for shared ownership, RefCell/Mutex/RwLock for interior mutability, and indices into a Vec (a “generational arena”) instead of pointers between nodes. Reaching for raw pointers to “get around” the borrow checker is almost always a sign you should reach for one of these instead.
“I need to reinterpret these bytes.” std::mem::transmute is unsafe and a classic foot-gun. The safe, total, endianness-defined functions to_be_bytes/from_le_bytes/as_bytes, the bytemuck crate, and TryFrom cover the vast majority of real byte-wrangling.
“I need SIMD.” The autovectorizer often emits it from a plain loop. When you need explicit control, the safe wrappers around std::arch and the wide/pulp crates give safe SIMD APIs on stable; portable std::simd is also coming but is currently nightly-only (the portable_simd feature, tracking issue #86656).

The throughline: in JavaScript “going native” is the only way to go fast or go low-level, so the instinct is to escape the language. In Rust, safe Rust is already the low-level language; the escape hatch is for crossing a language boundary, not for going faster within Rust.

Key Differences

Question	TypeScript/JavaScript answer	Rust answer
”How do I make this CPU-bound code fast?”	Drop to a native addon (C++/Rust `.node`).	Stay in safe Rust; it’s already native. Profile, then maybe `unsafe`.
”How do two parts share one mutable thing?”	Just pass the object — everything is a shared ref.	`Rc`/`Arc` + `RefCell`/`Mutex`, or arena indices. Raw pointers are a last resort.
”What happens if I get the low-level code wrong?”	A thrown `Error` or a process crash you can observe.	Undefined behavior — may corrupt data silently, may “work” until it doesn’t.
Default posture toward the escape hatch	Avoid native addons unless measured.	Avoid `unsafe`/FFI unless required by a language boundary or measured.
Who is responsible for safety inside it?	The V8/Node runtime, mostly.	You. The compiler stops checking; the `// SAFETY:` comment is your proof.
Can tooling tell me it’s there?	Hard (binary blob).	Yes: `#![forbid(unsafe_code)]`, `cargo geiger`, grep for `unsafe`.

The most important row is the third. A bug in a Node native addon typically segfaults the process — bad, but observable and local. A bug in Rust unsafe is UB: the compiler is now allowed to assume your invariant held, so it may optimize based on a false premise, producing corruption that surfaces far from the cause. This is why the bar for unsafe is higher than the bar for a native addon, not lower.

Common Pitfalls

Pitfall 1: Using `unsafe` to “reinterpret” bytes when a safe API exists

A developer wants the four bytes of a u32 and reaches for transmute. It does not even compile outside unsafe — and that compiler error is the language telling you to stop and reconsider:

1
fn main() {
2
    // does not compile (error[E0133]: call to unsafe function is unsafe and requires unsafe block)
3
    let bytes: [u8; 4] = std::mem::transmute(0x4142_4344_u32);
4
    println!("{bytes:?}");
5
}

The real error from cargo build:

1
error[E0133]: call to unsafe function `std::intrinsics::transmute` is unsafe and requires unsafe block
2
 --> src/main.rs:3:26
3
  |
4
3 |     let bytes: [u8; 4] = std::mem::transmute(0x4142_4344_u32);
5
  |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
6
  |
7
  = note: consult the function's documentation for information on how to avoid undefined behavior

The fix is not to add unsafe { } — it is to use the safe, explicit, endianness-defined API. transmute would silently give you platform-dependent byte order, which is a latent bug. The safe functions force you to say which order you mean:

1
fn main() {
2
    let value: u32 = 0x4142_4344;
3
    let be = value.to_be_bytes(); // big-endian: [0x41, 0x42, 0x43, 0x44]
4
    let le = value.to_le_bytes(); // little-endian
5
    println!("be = {be:?}");
6
    println!("le = {le:?}");
7

8
    // Reinterpreting back is itself a safe, total function:
9
    let back = u32::from_be_bytes(be);
10
    println!("round-trips: {}", back == value);
11
}

1
$ cargo run
2
be = [65, 66, 67, 68]
3
le = [68, 67, 66, 65]
4
round-trips: true

Pitfall 2: Reaching for raw pointers to “beat the borrow checker”

The classic case is “I need two mutable views into one buffer, so I’ll cast to *mut.” You do not — split_at_mut is a safe standard-library function whose unsafe is already written, audited, and tested inside std:

1
// "I need two mutable views into one Vec, which requires raw pointers." No —
2
// std gives you split_at_mut, a SAFE function whose unsafe is already audited.
3
fn normalize_halves(data: &mut [f64]) {
4
    let mid = data.len() / 2;
5
    let (left, right) = data.split_at_mut(mid); // two non-overlapping &mut, safely
6

7
    let lmax = left.iter().cloned().fold(0.0_f64, f64::max).max(1.0);
8
    let rmax = right.iter().cloned().fold(0.0_f64, f64::max).max(1.0);
9

10
    for x in left.iter_mut() {
11
        *x /= lmax;
12
    }
13
    for x in right.iter_mut() {
14
        *x /= rmax;
15
    }
16
}
17

18
fn main() {
19
    let mut data = vec![2.0, 4.0, 10.0, 5.0];
20
    normalize_halves(&mut data);
21
    println!("{data:?}");
22
}

1
$ cargo run
2
[0.5, 1.0, 1.0, 0.5]

If you had hand-rolled this with raw pointers, you would own the proof that the two views never overlap. split_at_mut is that proof, written once and reused. The general lesson: when the borrow checker rejects a sound pattern, look for the safe std/crate function that already encapsulates it before writing your own unsafe.

Pitfall 3: Assuming `unsafe` is the path to performance

unsafe does not make code fast; it removes a check, and the checks safe Rust adds are usually free in release builds (the optimizer elides provable bounds checks and vectorizes loops). Worse, you can make code slower with unsafe: raw-pointer aliasing can defeat optimizations the compiler performs under safe-reference aliasing guarantees. The honest path is in Section 21: Performance: write safe code, profile with cargo bench/criterion, and only consider unsafe against a measured, specific hot spot — with the benchmark to prove the win.

Pitfall 4: Treating FFI as “free interop”

Calling a C function looks like calling a Rust function, but every FFI call carries hidden obligations: the C side may not be thread-safe, may expect you to free memory it allocated (or it frees memory you must not touch), may use a different string encoding, and crashes it causes are UB on the Rust side too. A native addon also forces a C toolchain into your build and CI. If a pure-Rust crate covers the need, it eliminates an entire category of build-and-safety problems — that is a real engineering win, not laziness.

Best Practices

Default to safe; make unsafe/FFI justify itself. Treat every unsafe block as code requiring a written rationale and review. The standard is “what invariant am I promising, and why is it true here?”
Search the ecosystem first. Before FFI, look for a pure-Rust crate (crc32fast, ring/rustls instead of OpenSSL, image, regex, sha2, flate2). Before raw pointers, look for the std type that already solves it (Rc, RefCell, VecDeque, split_at_mut, slotmap, crossbeam).

Prefer safe concurrency and parallelism over native escape hatches. A CPU-bound aggregation that feels like it needs C is usually a rayon parallel iterator away — no unsafe, scales across cores:

1
// src/main.rs  —  Cargo.toml: rayon = "1.12"
2
use rayon::prelude::*;
3

4
// A CPU-bound aggregation a TS dev might think "needs C / a native addon."
5
// In Rust the SAFE answer is data parallelism via rayon — no unsafe, no FFI.
6
// Integers keep the result exact: u64 addition is associative, so the
7
// parallel reduction gives the same total no matter how rayon splits the work.
8
fn sum_of_squares(data: &[u64]) -> u64 {
9
    data.par_iter().map(|x| x * x).sum()
10
}
11

12
fn main() {
13
    let data: Vec<u64> = (0..1_000u64).collect();
14
    println!("sum of squares = {}", sum_of_squares(&data));
15
}

1
$ cargo run --release
2
sum of squares = 332833500

Note: This uses u64 deliberately. Integer addition is associative, so the parallel reduction is fully deterministic. With f64, floating-point addition is not associative, so the exact low-order digits of a parallel sum depend on how the work was split across threads — useful to know before you print a fixed float total as if it were stable.

Lock the door when you can. If a crate or module genuinely contains no unsafe, declare it and let the compiler enforce that forever:

1
// Crate-wide guarantee: "this crate contains zero unsafe code."
2
// CI fails if anyone sneaks an unsafe block in.
3
#![forbid(unsafe_code)]
4

5
fn main() {
6
    let p = 0xdead_beef_usize as *const i32;
7
    let value = unsafe { *p }; // does not compile under #![forbid(unsafe_code)]
8
    println!("{value}");
9
}

1
error: usage of an `unsafe` block
2
 --> src/main.rs:5:17
3
  |
4
5 |     let value = unsafe { *p }; // does not compile under #![forbid(unsafe_code)]
5
  |                 ^^^^^^^^^^^^^
6
  |
7
note: the lint level is defined here
8
 --> src/main.rs:1:11
9
  |
10
1 | #![forbid(unsafe_code)]
11
  |           ^^^^^^^^^^^

Remove the offending block and the crate is provably unsafe-free. Tools like cargo geiger audit an entire dependency tree for unsafe usage.

When you must use unsafe, isolate and document it. Keep it in the smallest possible block, wrap it in a safe API (safety-abstractions.md), write a // SAFETY: comment stating the invariant you uphold, and run it under Miri to catch UB the compiler can’t.
Measure before optimizing with unsafe. “Faster” is a claim that needs a benchmark. See Section 21: Performance.

Real-World Example

A practical decision walkthrough: you are building a service that needs to deduplicate and share a large in-memory catalog across request handlers. The instinct from JavaScript — “just hold references to the same objects everywhere” — translates in a naive Rust port to “I need raw pointers so handlers can share the catalog and mutate it.” That instinct is wrong; the safe tools cover it exactly.

1
use std::cell::RefCell;
2
use std::rc::Rc;
3

4
// The "two things point at one thing" pattern. In C you'd reach for raw
5
// pointers; in Rust the safe tools are Rc (shared ownership) + RefCell
6
// (runtime-checked interior mutability) — zero unsafe in YOUR code.
7
#[derive(Debug)]
8
struct Counter {
9
    value: i32,
10
}
11

12
fn main() {
13
    let shared = Rc::new(RefCell::new(Counter { value: 0 }));
14

15
    // Two independent owners of the SAME underlying Counter:
16
    let a = Rc::clone(&shared);
17
    let b = Rc::clone(&shared);
18

19
    a.borrow_mut().value += 1;
20
    b.borrow_mut().value += 41;
21

22
    println!("value = {}", shared.borrow().value);
23
    println!("strong refs = {}", Rc::strong_count(&shared));
24
}

1
$ cargo run
2
value = 42
3
strong refs = 3

Three owners (shared, a, b) point at one Counter, all mutate it, and the program is fully memory-safe with no unsafe anywhere. For a multithreaded server you would swap Rc/RefCell for Arc/Mutex (or RwLock) and gain compile-time data-race freedom — still no raw pointers.

The decision record for this feature would read: “Shared mutable catalog. Considered raw pointers (rejected: borrow-checker friction is a signal, not an obstacle). Considered FFI to a C cache library (rejected: no language boundary involved, adds toolchain). Chose Arc<RwLock<Catalog>> — safe, idiomatic, and the compiler proves the absence of data races.” That paper trail — what we considered and why we did not need the escape hatch — is the deliverable this page is teaching you to produce. The single time it should conclude “yes, use unsafe/FFI” is when a real language boundary or a measured, profiled bottleneck forces it.

Exercises

Exercise 1: Replace an FFI plan with a safe crate

Difficulty: Beginner

Objective: Build the reflex of searching crates.io before writing FFI.

Instructions: A colleague proposes adding a C dependency and an extern "C" binding to compute SHA-256 hashes “because OpenSSL is fast.” Without writing any unsafe or FFI, compute the SHA-256 of the bytes b"hello world" using a pure-Rust crate and print it as a lowercase hex string. (Hint: cargo add sha2, then Sha256::digest.) Confirm it prints the well-known value b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9.

Solution

1
// src/main.rs  —  Cargo.toml: sha2 = "0.11"  (or `cargo add sha2` for the current version)
2
use sha2::{Digest, Sha256};
3

4
fn sha256_hex(data: &[u8]) -> String {
5
    let digest = Sha256::digest(data);
6
    // Each byte -> two lowercase hex chars; no unsafe, no FFI.
7
    digest.iter().map(|b| format!("{b:02x}")).collect()
8
}
9

10
fn main() {
11
    println!("{}", sha256_hex(b"hello world"));
12
}

1
$ cargo run
2
b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

sha2 is pure, audited Rust with optional CPU acceleration — all the speed of a native hash with none of the FFI liabilities (no C toolchain, no manual memory management, no UB risk). When you genuinely must link an existing C library, the techniques are in calling-c.md; the point of this exercise is that you usually do not have to.

Exercise 2: Two mutable views without raw pointers

Difficulty: Intermediate

Objective: Recognize that “the borrow checker won’t let me alias” has a safe answer.

Instructions: You must write a function that, given &mut [i32], simultaneously holds a mutable view of the first half and the second half and adds the maximum of the second half to every element of the first half. A teammate insists this “requires casting to *mut i32.” Implement it with no unsafe, then state in one sentence which standard-library function made the unsafe unnecessary.

Solution

1
fn boost_first_half(data: &mut [i32]) {
2
    let mid = data.len() / 2;
3
    // split_at_mut yields two non-overlapping &mut slices — safely.
4
    let (front, back) = data.split_at_mut(mid);
5
    let boost = back.iter().copied().max().unwrap_or(0);
6
    for x in front.iter_mut() {
7
        *x += boost;
8
    }
9
}
10

11
fn main() {
12
    let mut data = vec![1, 2, 3, 10, 20, 30];
13
    boost_first_half(&mut data);
14
    println!("{data:?}");
15
}

1
$ cargo run
2
[31, 32, 33, 10, 20, 30]

slice::split_at_mut made the unsafe unnecessary: it is a safe standard-library function that returns two non-overlapping mutable slices, encapsulating (once, audited inside std) the very pointer reasoning the teammate wanted to hand-roll.

Exercise 3: Write the decision record

Difficulty: Hard

Objective: Practice the judgment this page is really about — deciding against unsafe/FFI and justifying it.

Instructions: You are designing an in-memory graph (nodes with edges to other nodes) for a routing service. The “obvious” implementation uses Box/raw pointers for node-to-node links and immediately fights the borrow checker. Choose a safe representation, implement a minimal version that compiles and runs (build a 3-node graph and print each node’s neighbor count), and write a two-to-three-sentence decision record explaining why you did not use raw pointers or FFI. (Hint: store nodes in a Vec and represent edges as indices — usize — into that Vec, a “generational arena” pattern.)

Solution

Representing edges as indices into a Vec sidesteps the self-referential-pointer problem entirely: indices are plain usize values the borrow checker is happy with, there is no aliasing to prove, and the whole structure is Copy-friendly and serializable for free.

1
struct Node {
2
    label: String,
3
    edges: Vec<usize>, // indices into Graph::nodes, not pointers
4
}
5

6
struct Graph {
7
    nodes: Vec<Node>,
8
}
9

10
impl Graph {
11
    fn new() -> Self {
12
        Graph { nodes: Vec::new() }
13
    }
14

15
    fn add_node(&mut self, label: &str) -> usize {
16
        let id = self.nodes.len();
17
        self.nodes.push(Node {
18
            label: label.to_string(),
19
            edges: Vec::new(),
20
        });
21
        id
22
    }
23

24
    fn add_edge(&mut self, from: usize, to: usize) {
25
        self.nodes[from].edges.push(to);
26
    }
27
}
28

29
fn main() {
30
    let mut g = Graph::new();
31
    let a = g.add_node("A");
32
    let b = g.add_node("B");
33
    let c = g.add_node("C");
34
    g.add_edge(a, b);
35
    g.add_edge(a, c);
36
    g.add_edge(b, c);
37

38
    for node in &g.nodes {
39
        println!("{} -> {} neighbor(s)", node.label, node.edges.len());
40
    }
41
}

1
$ cargo run
2
A -> 2 neighbor(s)
3
B -> 1 neighbor(s)
4
C -> 0 neighbor(s)

Decision record: Considered Box/raw-pointer node links (rejected: self-referential pointers fight the borrow checker and would require an unsafe core to make sound). Considered FFI to a C graph library (rejected: no language boundary is involved, and it would add a C toolchain to CI). Chose index-based edges into a Vec — fully safe, no unsafe, trivially serializable, and the standard “arena” idiom; if profiling later showed indexing to be a measured bottleneck we would revisit, but not before. The production-grade version of this idiom is the slotmap or petgraph crate, which adds generational indices to prevent stale-index bugs — again, safe Rust off the shelf.

Next: ↑ Section 20: Unsafe & FFI — return to the section landing page, or revisit Building Safe Abstractions for the times you do need unsafe.

Going further: Section 21: Performance → — the disciplined, measure-first home for the “but is unsafe faster?” question.

When `unsafe` and FFI Are Actually Necessary (and the Many Times They Are Not)

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

The genuinely necessary cases

The seductive-but-usually-wrong cases

Key Differences

Common Pitfalls

Pitfall 1: Using `unsafe` to “reinterpret” bytes when a safe API exists

Pitfall 2: Reaching for raw pointers to “beat the borrow checker”

Pitfall 3: Assuming `unsafe` is the path to performance

Pitfall 4: Treating FFI as “free interop”

Best Practices

Real-World Example

Further Reading

Official documentation

Exercises

Exercise 1: Replace an FFI plan with a safe crate

Exercise 2: Two mutable views without raw pointers

Exercise 3: Write the decision record

When unsafe and FFI Are Actually Necessary (and the Many Times They Are Not)

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

The genuinely necessary cases

The seductive-but-usually-wrong cases

Key Differences

Common Pitfalls

Pitfall 1: Using unsafe to “reinterpret” bytes when a safe API exists

Pitfall 2: Reaching for raw pointers to “beat the borrow checker”

Pitfall 3: Assuming unsafe is the path to performance

Pitfall 4: Treating FFI as “free interop”

Best Practices

Real-World Example

Further Reading

Official documentation

Related sections in this guide

Exercises

Exercise 1: Replace an FFI plan with a safe crate

Exercise 2: Two mutable views without raw pointers

Exercise 3: Write the decision record

When `unsafe` and FFI Are Actually Necessary (and the Many Times They Are Not)

Pitfall 1: Using `unsafe` to “reinterpret” bytes when a safe API exists

Pitfall 3: Assuming `unsafe` is the path to performance