Starting from a Tool That's 4x Faster: A Non-Programmer's Look at Rust

In my last post, I wrote about scanning 95 Twitter accounts with Actionbook. Throughout that process, one number kept nagging at me —

Fetching the latest tweets from a single account: Actionbook took 2 seconds, Playwright took 8.

Four times faster.

At the time I didn’t think much of it — good tool, keep using it. But later, while reading discussions about Actionbook online, I noticed that many developers spoke highly of the author, calling them a “veteran builder.” That got me thinking: if someone that skilled chose to build with this technology, there must be a good reason.

So I checked Actionbook’s GitHub page and found one line: Written in Rust.

Rust? I’d heard the name in passing but never looked into it. But since a tool that gave me a tangible speed difference was built with it, it seemed worth spending some time understanding what it actually is.

What Is Rust

Rust is a programming language that released version 1.0 in 2015, originally created by Mozilla (the company behind Firefox). As of January 2026, the latest version is 1.93.0.

Officially, it’s called a “systems programming language.” In plain terms: it’s built for writing software where performance really matters — operating systems, browser engines, databases, that kind of thing.

This used to be C and C++ territory. What Rust does differently: it runs about as fast as C/C++, but programs are much less likely to crash.

Who Uses Rust

If you’ve used any of these tools, you’ve already been using Rust indirectly:

• ripgrep — a code search tool that’s dozens of times faster than traditional grep. VS Code’s global search runs on it under the hood
• SWC — a JavaScript/TypeScript compiler. Next.js uses it by default instead of Babel
• Turbopack — Next.js’s new bundler, built by Vercel
• Deno — a Node.js alternative, rewritten in Rust by Ryan Dahl, the creator of Node.js himself
• agent-browser — a browser automation tool by Vercel Labs, the engine powering Actionbook
• Cloudflare Workers — one of the world’s largest CDNs, with its runtime written in Rust

There’s a clear trend: tools originally written in JavaScript, Python, or C++ are being rewritten in Rust. And after the rewrite, user feedback usually boils down to one word — fast.

Why It’s Fast: Three Core Reasons

I’m not a programmer, but I’ll try to explain these using analogies.

1. Pre-translated Book vs. Live Interpreter

Python and JavaScript are “interpreted languages.” Every time you run them, a “translator” converts your code into machine instructions in real time.

Rust is a “compiled language.” After writing the code, you spend time upfront translating everything into machine code, producing an executable file. After that, it runs directly — no more translation needed.

Think of it this way: interpreted languages are like bringing a live interpreter to a meeting — every sentence gets translated on the spot. Compiled languages are like translating the entire meeting transcript beforehand and just reading the finished version during the meeting. Obviously faster.

2. Clean Your Own Desk vs. Wait for the Janitor

Java, Go, JavaScript, Python — they all have a “garbage collector” (GC). As a program runs, it constantly creates temporary data. The GC periodically cleans up unused data to free memory.

The problem: when the GC is cleaning, the program has to pause briefly. Each pause is only milliseconds, but they add up to noticeable latency.

Rust has no GC. It uses a set of rules called the “ownership system” that resolves all memory management at compile time. The compiler checks when every piece of memory should be allocated and freed. If something’s wrong, it won’t compile — it refuses to let you run a broken program.

Think of it this way: languages with GC are like hiring a janitor who comes by every so often to clean your desk — you have to pause your work and wait. Rust is like designing the workspace so well from the start that everything has a fixed spot and returns there automatically — no janitor needed.

3. Elegant Code, No Performance Penalty

This one’s a bit more technical. In short: Rust lets you write code in a high-level, elegant style, but the compiled output runs as fast as hand-written low-level code.

Many languages force a trade-off between “easy to write” and “fast to run.” Rust’s design goal is to have both.

Why Developers Love Rust So Much

Stack Overflow runs an annual global developer survey. On the “most admired programming language” list, Rust has been #1 for multiple consecutive years. In the 2024 survey, 83% of developers who’d used Rust wanted to keep using it. In 2025, that number was 72%, still holding the top spot.

The reason is straightforward: fast and safe.

C/C++ is fast, but writing C/C++ makes it very easy to introduce memory errors — null pointers, buffer overflows — the root causes of security vulnerabilities. A huge number of security incidents in history trace back to memory errors.

Rust’s compiler catches potential memory problems before your program even runs. C-level performance, without worrying that one small oversight will bring your server down.

If It’s So Good, Why Doesn’t Everyone Use Rust?

After learning all this, my first reaction was: if Rust is fast and safe, why don’t programmers just write everything in Rust from the start?

After some digging, the answer turned out to be very practical — Rust is really hard to learn.

The ownership system that makes Rust fast and safe comes at a cost: programmers have to think through the lifetime of every piece of memory while writing code. Other languages don’t require this — the GC handles it for you. Rust’s compiler will reject your code over and over until you get the memory management exactly right. Many developers say that the first few months of learning Rust are mostly spent arguing with the compiler.

Beyond the learning curve, there’s an even more practical issue: not everything needs to be that fast. Writing an internal data processing script? Python gets it done in 30 minutes; Rust might take half a day. A web API that responds in 50ms instead of 5ms? Users can’t tell the difference. There’s a real trade-off between excess performance and development speed.

So the reality is: Rust is ideal for infrastructure and tools that demand peak performance and reliability — CLIs, compilers, runtimes, database engines. For business logic, quick prototypes, and data analysis, Python and JavaScript’s development speed advantage wins out.

This also explains why Rust’s adoption pattern is “rewrite” rather than “build from scratch” — validate the idea quickly in Python/JS first, then rewrite the performance-critical parts in Rust once you’ve confirmed that’s the bottleneck.

Then Why Not Just Have AI Write Rust?

My immediate follow-up thought was: we’re all doing vibe coding now, using AI to write code. If Rust is hard to learn but performs well, why not just let AI handle the Rust complexity for us? Humans don’t have to suffer through the learning curve; the machine deals with it.

After looking into it, this idea isn’t just reasonable — it’s already happening.

Today’s AI models are already quite good at writing Rust. Claude Opus 4.5 ranks first in 7 out of 8 programming languages on SWE-bench Multilingual, including Rust. Even more striking, one developer used Claude to produce 70,000 lines of Rust compiler code in just two weeks. Shuttle (a Rust cloud platform) tested Claude generating a complete Rust full-stack web application — with database, frontend, and deployment config — from a single prompt.

And here’s something counterintuitive: Rust’s strict compiler is actually an advantage for AI coding. When Python code has a bug, it might only surface at runtime, and you have to debug it yourself. When Rust code has an issue, the compiler tells you exactly which line has what problem. This precise error feedback is incredibly AI-friendly — AI can use the compiler’s messages to fix issues accurately, creating an efficient “write → compile → fix” loop.

So the “hard to learn” barrier that Rust presents? It’s a problem for humans, but not really for AI. Rust + AI might be an even better combination than people think: AI handles Rust’s complexity, humans enjoy Rust’s performance. “Fast but hard to write” is becoming “fast and easy to write.”

In Practice: Should I Have AI Write My Projects in Rust?

After reaching this conclusion, I had a more concrete question: I’m using Claude Code for vibe coding right now — can I just tell it to write everything in Rust?

After looking into real-world cases, the answer is more optimistic than I expected. One developer used Claude Code to write a Rust extension to optimize his Python data pipeline. Claude generated working code almost on the first try, delivering a 10-50x performance boost. The key detail — he didn’t know Rust himself.

A HackerNoon article specifically about coding Rust with Claude Code reached this core conclusion: Rust’s strict compiler actually makes AI-generated code more reliable. “If it compiles, it probably works” isn’t just a Rust community motto — it’s becoming the actual experience of AI-assisted development.

But the real friction isn’t in AI writing the code — it’s in the broader ecosystem.

Rust compile times are much slower than Python. Every code change requires waiting for compilation. Web development libraries and frameworks are far less mature than Python’s or JavaScript’s. When you search for help, Python answers outnumber Rust answers by orders of magnitude. Deployment and packaging are more complex too.

So the question isn’t “can AI write Rust” — it’s “does your project need Rust right now?”

The practical best practice is phased: start with Python for a quick MVP to validate the idea, then rewrite the performance bottlenecks in Rust once confirmed. It’s not A or B — it’s A first, then B.

That developer’s approach is the textbook example: he first wrote a working Python version, then used it as a “reference answer” for AI to rewrite the same logic in Rust. The Python version served as both the prototype and the test case for verifying the Rust version’s correctness.

What I Took Away as a Non-Programmer

Honestly, I can’t write Rust, and probably won’t learn anytime soon. But this journey from “this tool is fast” to “why is it fast” gave me a few new perspectives:

“Written in Rust” is becoming a quality signal. Just like “rewritten in Go” ten years ago meant a team was serious about concurrency, “Written in Rust” now signals a pursuit of peak speed and reliability. When I saw that line on Actionbook’s README, I had a performance expectation — and the benchmarks confirmed it.

You don’t need to write Rust to benefit from it. Next time you’re choosing between two tools with the same functionality — one written in Python, one in Rust — pick the Rust one. It’s almost certainly faster and lighter on resources.

The technical choices behind good tools follow a logic. Actionbook isn’t fast because of magic. It’s fast because Rust was designed from day one to pursue the unity of speed and safety. Understanding this logic gives you one more dimension for evaluating tools.

It’s like buying a car — you don’t need to understand engine mechanics, but knowing that a turbocharged engine delivers more power than a naturally aspirated one at the same displacement gives you one more data point.

Rust is basically the turbocharger of the programming language world.