Big news from Meta this week. WhatsApp replaced its C++ media handling library with Rust, and the scale is unprecedented: billions of devices across Android, iOS, macOS, Web, and wearables.
This is the largest client-side Rust deployment I'm aware of. When a company serving 3 billion daily users rewrites critical infrastructure in Rust, it signals something significant about enterprise adoption.
In this issue: WhatsApp's Rust migration, why Claude Code uses ripgrep instead of embeddings, PostgreSQL FFI performance gains, async blocking pitfalls, and more.
Let's dive in.
WhatsApp Rewrites Media Library in Rust
Meta's engineering team published an in-depth writeup on rewriting "wamedia," WhatsApp's media handling library, from C++ to Rust. The numbers tell the story: 160,000 lines of C++ became 90,000 lines of Rust, including tests.
The rewritten library powers a security system called "Kaleidoscope" that validates media files and detects malicious content. Every image, video, and document flowing through WhatsApp now passes through Rust code before reaching users.
What stands out is their migration approach. Instead of a risky big-bang rewrite, Meta ran both implementations in parallel using differential fuzzing. The C++ and Rust versions processed the same inputs, and any discrepancy triggered investigation. This strategy let them catch subtle bugs before they reached production.
The Hacker News discussion praised this approach. One commenter called it "exactly how you do a safe migration at scale." The binary size overhead (around 200KB) was addressed through Buck2 build optimizations.
Performance and memory usage improved over the original C++. Meta attributes this partly to Rust's ownership model encouraging cleaner data flow patterns.
Takeaways:
- Rust is viable for client-side deployments at massive scale
- Differential fuzzing enables safe migrations without big-bang risk
- The rewrite reduced code size by 44% while adding comprehensive tests
Why Claude Code Chose ripgrep Over Vector Search
Here's a counterintuitive choice: while most AI coding tools rush to implement vector databases and embeddings, Claude Code relies on ripgrep for code search. Not RAG pipelines. Just fast, reliable text search written in Rust.
Claude Code bundles ripgrep via the @vscode/ripgrep npm package, the same battle-tested dependency that powers VS Code's search. It works immediately on any codebase with no indexing required.
The advantages are significant: exact matches instead of semantic approximations, automatic .gitignore respect, and predictable behavior. You know exactly what it's searching.
A Hacker News commenter pointed out this is still technically RAG, just using information retrieval techniques that have existed for decades. Sometimes proven approaches beat newer alternatives.
I wrote a deeper dive on this topic covering ripgrep's architecture, the VS Code connection, and configuration tips for Claude Code users.
Takeaways:
- Zero indexing time means instant productivity on new codebases
- Exact text matching avoids semantic drift of embeddings
- ripgrep demonstrates Rust's value proposition: C-level performance with memory safety
Replacing Protobuf with Direct Rust FFI
A detailed post from PgDog shows how they eliminated Protocol Buffers by using direct C-to-Rust FFI bindings. The performance gains are substantial: 5.45x faster parsing and 9.64x faster deparsing compared to the Protobuf version.
The approach bypasses serialization entirely. Instead of converting data to Protobuf format and back, they pass pointers directly between C and Rust code. This works because PgDog controls both sides of the interface, so they don't need language-agnostic serialization.
The tradeoff is clear: you lose cross-language compatibility but gain significant performance. For internal services where you control the entire stack, removing the serialization layer cuts out both latency and complexity.
Takeaways:
- Direct FFI can dramatically outperform serialization-based approaches
- Consider this when you control both ends and need maximum performance
- The 5-10x speedup comes from eliminating data transformation entirely
The Hidden Bottleneck: Blocking in Async Rust
A walkthrough from cong-or.xyz tackles one of the most common async Rust mistakes: accidentally blocking the runtime. This bug works fine in testing but tanks performance in production.
The article explains why calling synchronous code (file I/O, CPU-heavy computations, or blocking network calls) inside an async context starves other tasks. The Tokio runtime can't preempt your code, so one blocking call holds up the entire thread pool.
The fix depends on the situation. For CPU-bound work, use spawn_blocking to move it off the async threads. For blocking I/O, switch to async alternatives or wrap in spawn_blocking. The post includes concrete examples showing the performance difference.
Takeaways:
- Blocking calls inside async functions prevent other tasks from running
- Use
spawn_blockingfor CPU-bound or unavoidably blocking operations - Profile your async code to find hidden synchronous bottlenecks
SIMD Programming in Pure Rust
Sylvain Kerkour published a practical introduction to SIMD in Rust that cuts through the complexity. Instead of diving into architecture-specific intrinsics, the guide focuses on portable SIMD using the experimental std::simd module.
The tutorial builds up from basic vector operations to real speedups. What makes it valuable is the emphasis on when SIMD helps versus when it doesn't. Spoiler: if your data isn't already contiguous in memory, you'll spend more time shuffling bytes than computing.
The portable approach means your code works on x86, ARM, and WebAssembly without conditional compilation. You write once, and the compiler picks the best instructions for each target.
Takeaways:
- std::simd provides portable SIMD without platform-specific intrinsics
- Memory layout matters more than instruction choice for real speedups
- Start with the high-level API before reaching for raw intrinsics
Snippets
We are thrilled to have you as part of our growing community of Rust enthusiasts! If you found value in this newsletter, don't keep it to yourself — share it with your network and let's grow the Rust community together.
👉 Take Action Now:
Share: Forward this email to share this newsletter with your colleagues and friends.
Engage: Have thoughts or questions? Reply to this email.
Subscribe: Not a subscriber yet? Click here to never miss an update from Rust Trends.
Cheers,
Bob Peters
Want to sponsor Rust Trends? We reach thousands of Rust developers biweekly. Get in touch!