I just finished reading an about Arti - the Rust Rewrite of Tor -Some articles explaining why the Tor Project is rewriting their classic C daemon in Rust. Overall? Solid B+. It’s clear, convincing, and a great intro for developers curious about Arti. But as someone who’s spent time in both C and Rust networking code, I spotted a few gaps worth talking about. Here’s my honest review – strengths, weaknesses, and what I’d add to make it excellent. The author lists three pain points: memory safety bugs, monolithic architecture, and concurrency challenges. No fluff. This is exactly why the Tor Project started looking elsewhere after two decades. specifics Not just “Rust is safe” – they mention ownership, borrow checker, async/await, and Cargo. That’s the kind of detail engineers actually need. “First-class concurrency” using async/await – yes. Legacy Tor’s state machines were notoriously painful. tor-proto, tor-netdir, tor-circmgr, arti-client – showing a real modular architecture makes the rewrite feel tangible. The example of embedding arti-client into a chat app is perfect. They clearly separate what’s done (client parity for browsing) from what’s aspirational (relay rewrite). No overpromising. The article never answers: Is Arti faster or slower? Latency, memory footprint, circuit establishment time – these are the first questions any performance‑sensitive developer asks. One sentence would fix this: “Early benchmarks show Arti matches the C client’s throughput while using ~20% less memory.” (Even if the numbers are rough.) unsafe Rust Rust isn’t a magic wand. Cryptography (curve25519, AES‑GCM) and some FFI glue require unsafe blocks. The Tor Project has audited them carefully, but pretending they don’t exist weakens the article’s credibility. Add a short paragraph: “Of course, crypto crates like x25519-dalek use small, audited unsafe sections – but that’s orders of magnitude less risk than the entire C codebase.” How do we switch from C to Arti without breaking the network? Can both clients coexist? What happens to legacy relays? Even two sentences would show the author has thought about real-world deployment. The article quotes “The Tor Project” but doesn’t link to their blog or official Arti announcements. Adding 2–3 footnotes would turn good claims into verifiable facts. Issue Why it matters No mention of which async runtime (tokio vs async-std) Runtime choice affects embedded use cases No comparison of crypto backends (OpenSSL vs RustCrypto) OpenSSL has a long CVE history – worth noting Assumes reader knows what “cell serialization” means A one‑sentence explanation would help beginners Should you read the original article? Yes – if you’re a developer curious about Tor, Rust in production, or privacy engineering. It’s a clean, motivating overview. But don’t stop there. Pair it with the Tor Project’s official Arti status updates and Nick Mathewson’s talks. The real juicy details (performance, unsafe policy, async runtime choices) live in those primary sources. My rating: ⭐⭐⭐⭐ (4/5) Great for what it covers. One more revision with perf data and a nod to unsafe would make it a true 5/5. Thanks to the author for writing this – and thanks to the Tor Project for making the internet a safer place, one line of Rust at a time. 🐧🔒 What do you think? Have you tried embedding Arti in a project? Drop your thoughts below.