You’ve probably heard it a thousand times: Rust is the speed king. The language with zero-cost abstractions, fearless concurrency, and manual memory management that makes C blush. So when a Swift implementation of a tokenizer casually beats the Rust reference implementation, something feels wrong. Like finding out the underdog just knocked out the champion in the first round.
That’s exactly what happened with Swift-Gigatoken. A GitHub repo. A single comment: “Interestingly, it’s faster than its reference implementation in rust ( :”
The real story isn’t that Swift beat Rust. It’s that your gut feeling about language performance is a lie.
Let’s be clear: this isn’t a language war. It’s a wake-up call. You and I have been trained to treat benchmarks as verdicts. “Rust is faster than Swift.” “Python is slow.” “C++ is the gold standard.” We repeat these mantras until they feel like physics. But they’re not physics. They’re habits. And habits make us lazy.
What this Swift tokenizer actually proves is that algorithm design and workload-specific optimization beat default tooling assumptions every single time. The Rust implementation might have been written quickly, without the same level of profiling and tuning. The Swift implementation might have exploited a specific memory access pattern that plays to its reference counting strength. The result? A headline that screams “Swift faster than Rust!” — but the real lesson is buried in the fine print.
I’ve seen this firsthand. In another project, a team spent months rewriting a hot loop in Rust, only to discover that a well-optimised C++ version with SIMD instructions was 2x faster. The language wasn’t the bottleneck. The assumptions were.
So here’s the twist: This isn’t a victory for Swift. It’s a victory for the developer who actually benchmarked their own workload. The minute you hand over your performance decisions to a language stereotype, you’ve already lost.
What does this mean for you? If you’re building performance-sensitive systems, stop reading blog posts that declare one language faster than another. Instead, grab your specific data, your specific patterns, and your specific constraints. Write a prototype. Profile it. Iterate. Then decide.
And if you’re a Swift developer, enjoy the rare bragging rights — but don’t get comfortable. The next benchmark might flip the script. The only constant is that the language that wins is the one designed for the problem you’re actually solving.
Next time someone says “Swift is faster than Rust,” don’t buy the headline. Buy the benchmark. And then buy your own.
FAQ
Q: Is this benchmark truly representative of the two languages?
A: No, it's a single case. The Rust implementation may not have been optimized for the specific workload. The point is to avoid generalizing from one data point. Always demand to see the full implementation before drawing conclusions.
Q: What's the practical implication for developers choosing between Swift and Rust?
A: Don't choose based on a single benchmark. Run your own tests with your own data, patterns, and constraints. The language that wins is the one designed for the problem you're actually solving, not the one with the best reputation.
Q: What's the contrarian take on this result?
A: The real story is that Swift's automatic memory management can sometimes outperform Rust's manual ownership when the algorithm is tailored to the workload. It's a reminder that 'zero-cost abstractions' are only zero-cost if you actually use them correctly.