Ffi on

Lesson 10: Soundness — The ultimate safety guarantee

Fri, 04 Jul 2025 16:50:00 +0000

A few months ago, someone filed a soundness bug against a crate I maintained. The report was elegant — three lines of safe code that triggered a use-after-free through my API. No unsafe in the caller’s code. The bug was in my unsafe implementation. I fixed it within the hour, cut a patch release, and filed a CVE advisory. That’s the social contract of soundness in Rust: if safe code can cause undefined behavior, the bug is always in the library.

Lesson 9: napi-rs — Rust extensions for Node.js

Tue, 01 Jul 2025 13:26:00 +0000

We had a Node.js microservice that validated JWTs. Under load, the jsonwebtoken npm package was burning 40% of CPU on RSA signature verification. I wrote the verification in Rust with napi-rs, dropped it in as a replacement, and CPU usage fell to 8%. The JavaScript API didn’t change at all — same function name, same arguments, same return type. Just 5x faster.

napi-rs is to Node.js what PyO3 is to Python. You write Rust, export it as a native Node addon, and call it from JavaScript like any other module. The framework handles all the N-API complexity, type marshaling, and async integration.

Lesson 8: PyO3 — Rust extensions for Python

Sat, 28 Jun 2025 08:14:00 +0000

I had a Python service that processed 2 million JSON records daily. Profiling showed 80% of the time was spent in one function — a custom similarity scoring algorithm. I rewrote that single function in Rust with PyO3. Same API, same tests, same deployment. Processing time dropped from 47 minutes to 90 seconds. The Python team didn’t have to learn Rust, didn’t have to change their imports, didn’t even notice — they just saw their pipeline get 30x faster.

Lesson 7: Exposing Rust to C — cdylib and cbindgen

Wed, 25 Jun 2025 15:40:00 +0000

A team I was advising had a massive C codebase — about 400,000 lines of networking code. They wanted to rewrite their TLS handling in Rust but couldn’t justify a full rewrite. The solution: build Rust as a shared library, expose a C-compatible API, and link it into the existing build. Took a week to get the first version working. The memory safety bugs in that module dropped to zero.

Lesson 6: FFI — Calling C from Rust

Mon, 23 Jun 2025 11:55:00 +0000

My first real FFI project was binding to SQLite. I thought “how hard can it be — it’s just calling C functions.” Three days later I was debugging a segfault caused by a string lifetime issue where Rust freed a CString while SQLite was still reading from the pointer. That experience taught me more about unsafe Rust than any tutorial ever could.

Calling C from Rust is the most common FFI scenario. Every operating system API is C. Most high-performance libraries — OpenSSL, zlib, SQLite, libcurl — are C. If you’re writing systems software in Rust, you’ll need this skill.

Lesson 5: Building Safe Abstractions Over Unsafe Code — The encapsulation pattern

Fri, 20 Jun 2025 09:22:00 +0000

The standard library’s Vec<T> contains over 50 unsafe blocks. HashMap has even more. Yet you use both every day without thinking about safety — because their public APIs are entirely safe. The unsafe is invisible, encapsulated behind type system boundaries that make misuse impossible.

This is the most important pattern in Rust: unsafe internals, safe surface. Master it, and you can build anything.

The Core Principle

An unsafe block means “I’ve verified the invariants.” A safe API means “the type system prevents invariant violations.” The goal is to push all the verification into the implementation so that users of your code can’t break the invariants no matter what they do.

Lesson 4: transmute — Type punning and its dangers

Wed, 18 Jun 2025 17:08:00 +0000

I once watched a senior engineer transmute a Vec<u8> into a Vec<u32> and couldn’t figure out why it segfaulted on ARM but worked fine on x86. Spoiler: alignment. The allocator returned 1-byte-aligned memory for the u8 vec, and u32 needs 4-byte alignment. On x86 you pay a performance penalty; on ARM you get a bus error.

transmute is Rust’s most powerful unsafe tool. It reinterprets the bits of one type as another type. No conversion, no transformation — just “these bytes are now a different type.” That power makes it incredibly useful and incredibly dangerous.

Lesson 3: Dereferencing Raw Pointers Safely — The patterns that work

Mon, 16 Jun 2025 10:45:00 +0000

A colleague once showed me a bug that took them three days to find. Their unsafe code dereferenced a pointer that was valid when created but dangling by the time it was used — a classic lifetime mismatch. The fix was two lines. The debugging was seventy-two hours. That ratio is why this lesson exists.

Dereferencing raw pointers is the most common unsafe operation you’ll encounter, and getting it right means following specific patterns. Not guidelines — patterns. Repeatable, auditable approaches that make your unsafe code reviewable.

Lesson 2: Raw Pointers — const T, mut T and when you need them

Sat, 14 Jun 2025 14:17:00 +0000

The first time I used raw pointers in Rust, I was porting a ring buffer from C. I’d written ring buffers in C a dozen times — head pointer, tail pointer, wrap around, done. In Rust, the borrow checker wanted nothing to do with my two mutable pointers into the same buffer. That’s when I learned what raw pointers are actually for.

References vs Raw Pointers

Rust references (&T and &mut T) come with guarantees enforced by the compiler:

Lesson 1: What unsafe Actually Means — The contract you're signing

Thu, 12 Jun 2025 08:32:00 +0000

I spent my first six months writing Rust thinking unsafe meant “this code is dangerous and you should feel bad.” That misunderstanding cost me weeks — I’d bend over backwards to avoid it, writing convoluted safe wrappers around problems that genuinely needed a raw pointer or two. Once I actually read the Rustonomicon and understood what unsafe really means, everything clicked.

Let’s clear this up properly.

unsafe Is Not What You Think

Here’s the biggest misconception in the Rust ecosystem: unsafe does not mean “this code is broken” or “this code does bad things.” It means “I, the programmer, am upholding invariants that the compiler cannot verify.”