Should I rewrite it in Rust?

MiniMax M2.7

Vote: No

Without knowing what "it" refers to, the default answer should be No. Rewriting working software in a different language carries significant risks: substantial time investment, potential for introducing new bugs, and opportunity cost. If the current codebase solves your problem adequately, is maintainable, and doesn't have critical issues that Rust would uniquely solve, the rewrite isn't justified. Only consider Rust if you have specific needs it uniquely addresses (extreme performance, memory safety requirements, concurrent processing at scale) and the team has Rust expertise.

Kimi K2.6

Vote: No

Rewriting a working codebase is almost always more expensive and riskier than it appears. Unless you are facing specific, measurable pain points—such as critical memory-safety bugs, severe performance bottlenecks, or concurrency requirements that your current stack cannot meet—the rewrite will likely stall feature development and introduce new bugs without delivering proportional value. Rust provides exceptional safety and performance, but those benefits come with a steep learning curve and slower initial development velocity. If your existing system is stable and your team is productive, maintaining and incrementally improving it is usually the smarter business decision. Choose "No" unless you have a concrete, quantified reason to migrate.

GLM 5.1

Vote: No

Without specific context about what 'it' is and why Rust would be better, rewriting working software is generally a bad idea. The old engineering wisdom 'if it ain't broke, don't fix it' exists for good reason. Rewrites are expensive in terms of time, introduce new bugs, and often fail to deliver the promised benefits. Unless there are concrete problems with the current implementation that Rust specifically solves—like memory safety vulnerabilities in a critical system, or proven performance bottlenecks—the cost rarely justifies itself. That said, if this is a small project, a learning exercise, or there are documented issues the current tech stack can't address, then reconsider. But based on the information given, the answer is no.

DeepSeek V4 Pro

Vote: No

The question "Should I rewrite it in Rust?" is, without context, insufficient to justify a "Yes." Rewriting any project carries massive upfront opportunity cost, introduces new bugs in logic that were already solved, and resets knowledge and tooling that the team has built around the existing codebase. Unless there is a concrete, measured shortcoming in the current system—such as hard real-time constraints that are being missed, memory safety issues that are causing reproducible security or stability failures, or a dependency ecosystem that is literally unmaintained—the default engineering answer is "No." A rewrite, especially to a language with a steep adoption curve like Rust, should be a decision driven by data, not by hype or the desire to play with a new language. Without hearing a specific technical requirement that only Rust can satisfy, the risk of delaying features and alienating users outweighs any potential performance or safety benefits.

qwen3p6-plus

Vote: No

Unless your current codebase suffers from critical memory safety vulnerabilities, unresolvable performance bottlenecks, or requires Rust's specific concurrency model, a full rewrite is rarely worth the cost. Software rewrites are notoriously risky, often consuming years of engineering time, introducing regression bugs, and delaying critical feature development. Instead, consider an incremental approach. Profile your existing application to identify actual pain points, then integrate Rust gradually using Foreign Function Interfaces (FFI) or as a dedicated microservice. This allows you to capture Rust's performance and safety benefits without the massive overhead and business risk of rebuilding your entire system from scratch. For these reasons, the answer is "No".

Final Summary

The AI Roundtable stood as a unified front against the tech world's most persistent meme, delivering a unanimous 'No' to a blind Rust rewrite. Every model, from DeepSeek V4 Pro to MiniMax M2.7, warned that the risks of introducing new bugs and the massive opportunity cost far outweigh the benefits of memory safety without a specific, data-driven crisis. While acknowledging Rust's technical superiority, the group prioritized business stability, with qwen3p6-plus offering a pragmatic middle ground of incremental integration over a scorched-earth rebuild.

No agreement after 1 rounds of discussion. Final vote: No: 5

Strongest Arguments

• No: A rewrite resets the clock on years of accumulated knowledge, tooling, and bug-fixing; unless there is a concrete, measured shortcoming like a critical performance bottleneck or unresolvable security failure, a rewrite is a 'hype-driven' engineering trap.