You know that sinking feeling. You crack open a project, expecting something lean and mean. Instead, you find a 17-megabyte binary that does less than the 4-megabyte C++ version you could have written in an afternoon. Congratulations—you’ve just met Rust’s hidden tax.
Meet Curveball. A spline generator. That’s it. It takes control points, produces a smooth curve. A geometric algorithm so simple that a competent C++ programmer could knock it out in a few hundred lines. The Rust version? 17 megabytes of ‘sloppy Rust,’ as one commenter put it—and honestly, they’re being polite. The C++ equivalent fits comfortably under 4MB.
Rust promised us zero-cost abstractions. But this project proves that ‘zero-cost’ only applies to runtime performance, not to binary size, compile time, or cognitive overhead. For a spline generator, the costs are real and they’re showing up in your disk usage and your cache lines.
Now, before the Rust defenders sharpen their pitchforks, let me be clear: I love Rust for what it does well—concurrency, safety-critical systems, large codebases where memory bugs would be catastrophic. But for a simple geometric utility? The overhead of the standard library, the monomorphization of generics, the trait machinery—it all adds up. And when you’re building a small tool for an embedded system or a game engine, every kilobyte matters.
This isn’t a contrarian take for the sake of being difficult. It’s a wake-up call. The next time you reach for Rust because ‘everyone says it’s the best,’ ask yourself: Best at what? Safety? Yes. Performance? Usually. Minimalism? Absolutely not.
The developer who built Curveball chose Rust because it’s modern, it’s safe, it’s the hype. And they ended up with a binary that’s over four times larger than necessary. The comments on the project page are a goldmine of frustration: ‘I am so tired of this crappy language,’ one person wrote, summing up the sentiment of a generation of C++ devs who value compactness over cargo-culting new trends.
Here’s the uncomfortable truth: When you worship ‘modern’ without asking ‘what does it cost,’ you end up with bloated software that solves problems nobody asked you to solve. Rust’s borrow checker didn’t make the spline generator safer—it wasn’t needed. The real danger isn’t a double-free in a curve, it’s the assumption that more features, more language complexity, more abstractions always make things better.
Let’s twist the knife: The commenter also wrote, ‘It’s called a spline, felicia.’ They’re right. Reinventing the wheel with a sledgehammer doesn’t make you clever. It makes your binary fat.
So what’s the takeaway? If you’re writing small, well-understood algorithms—curve generators, JSON parsers, command-line utilities—think twice before committing to Rust. C++ can give you the same performance with a fraction of the bloat. And if you’re already in a Rust project, profile your binary size. Strip dead code. Consider using #![no_std] for truly minimal targets.
The future of systems programming isn’t about picking a side in a holy war. It’s about picking the right tool for the job—and sometimes, that tool looks a lot like 1998.
Now go write something small. Something that fits on a floppy disk. Your CPU—and your users—will thank you.
FAQ
Q: But Rust's safety guarantees are worth the extra size, aren't they?
A: Not for a spline generator. Safety is irrelevant when the algorithm has no memory-unsafe operations. Paying for a feature you don't use is just waste.
Q: What's the practical implication for my next project?
A: Profile your binary early. If you're building small utilities or embedded tools, benchmark Rust against C++ for size, not just speed. Often, the simpler language wins.
Q: Is this an argument against Rust entirely?
A: No. Rust excels at large, safety-critical codebases. The contrarian take is that Rust's 'zero-cost abstractions' are marketed as universal, but they come with real costs—binary bloat, compile time, and complexity—that can implode small projects.