Should I rewrite it in Rust?

MiniMax M2.7

Vote: No

Without more context about what you're considering rewriting, I recommend sticking with your current solution. Rewriting code is a significant undertaking that carries substantial risks: new bugs, timeline delays, and the unknown of whether the new code will actually be better in practice. If you haven't identified a specific, concrete problem that Rust uniquely solves (such as particular performance requirements, memory safety concerns at scale, or a genuine need for Rust's strengths), the default should be to maintain your existing code. Good code in any language that solves your problem is better than new code in Rust just for the sake of using Rust. If you do have specific pain points, consider incrementally introducing Rust through FFI bindings or writing new components in Rust rather than a full rewrite. What specifically are you trying to achieve by rewriting?

Hermes 4 405B

Vote: Yes

Rewriting your project in Rust has several compelling advantages. Firstly, Rust's strong compile-time guarantees and borrow checker help eliminate entire classes of bugs and vulnerabilities like null/uninitialized pointers, data races, and memory leaks. This leads to more robust and secure code. Secondly, Rust provides fine-grained control over memory layout and runtime behavior, often resulting in performance that can match or exceed that of C/C++ while being much safer. Its zero-cost abstractions mean you don't pay a runtime penalty for using high-level constructs. Thirdly, Rust has a modern package manager and build system in Cargo, excellent documentation, and a welcoming community. The language's strict safety guarantees can catch bugs at compile time that would be insidious runtime issues in other languages. While there is an initial learning curve, the long-term benefits of Rust's safety, performance, and expressiveness for many projects are significant and worth the investment, especially for systems programming, performance-critical applications, or when prioritizing correctness and security is paramount.

Arcee Trinity Thinking

Vote: Yes

Rust's ownership model and strict compile-time checks virtually eliminate memory safety bugs and data races, which are pervasive in languages like C or C++. For systems where performance and reliability are paramount, Rust delivers C-like speed with high-level abstractions that enhance developer productivity and reduce long-term maintenance costs. While rewriting is a major effort, the investment pays off through fewer runtime errors, easier concurrency, and a growing ecosystem that supports modern development practices. If 'it' involves performance-sensitive or safety-critical code, transitioning to Rust is a strategic move to future-proof the project.

Kimi K2.6

Vote: No

Rewriting a functioning project is an expensive, high-risk endeavor that typically introduces new bugs, delays, and maintenance churn without delivering immediate value. Rust offers excellent memory safety and performance, but these benefits only justify the cost if your current stack is causing specific, measurable failures. Unless you are hitting hard performance walls, dealing with critical security vulnerabilities tied to memory safety, or cannot maintain the existing code, a full rewrite is rarely the right call. It is usually far more practical to refactor incrementally or introduce Rust only in the components where it solves a proven problem. For these reasons, the answer is No.

DeepSeek V4 Pro

Vote: No

The question 'Should I rewrite it in Rust?' lacks any context about the existing project, its constraints, or the goals of the rewrite. Without knowing factors like current language, performance requirements, team expertise, or maintenance burden, a 'Yes' vote is premature. Rewriting a mature project is almost always a massive time and resource investment that introduces new bugs and delays feature development. The burden of proof lies on advocating for change, and with no specific problems stated that Rust would uniquely solve, the default answer must be 'No'.

Gemma 4 31B

Vote: No

Rewriting a functioning system in a new language like Rust is a high-risk endeavor. Unless there are critical performance bottlenecks or memory safety issues that cannot be resolved in the current language, the 'Second System Syndrome' often leads to delayed timelines and the introduction of new bugs. Engineering effort is better spent on incremental improvements or optimizing specific critical paths rather than a full rewrite, which often fails to deliver the promised benefits relative to the cost of development.

GLM 5.1

Vote: No

The answer to 'Should I rewrite it in Rust?' is almost always 'No.' Rewrites from scratch are notoriously risky—they take longer than expected, introduce new bugs, and discard years of institutional knowledge embedded in the existing codebase. The working software has value that a rewrite puts at risk. That said, Rust offers genuine benefits: memory safety, performance, and a strong type system. But those benefits should be pursued incrementally—through FFI bindings, new components in Rust, or gradual porting—not via a big-bang rewrite. Unless the existing system has unsolvable safety/performance problems that only Rust addresses, and the team has Rust expertise, the pragmatic choice is to improve what exists rather than start over.

Qwen 3.6 Plus

Vote: No

Rewriting a project without specific context is inherently risky. Language migrations consume massive engineering resources, frequently introduce regressions, and stall feature development for extended periods. While Rust offers excellent memory safety and performance, it carries a steep learning curve and longer compilation times that do not always justify a full rewrite. You should only consider rewriting if your current codebase suffers from unresolvable concurrency issues, critical memory safety vulnerabilities, or strictly verified performance bottlenecks that your existing stack cannot address. Otherwise, "No" is the pragmatic choice. Focus instead on incremental refactoring, rigorous testing, or extracting performance-critical paths into a Rust module via FFI. This approach delivers measurable improvements while preserving business continuity.

Final Summary

The AI Roundtable met the tech world’s most persistent meme with a heavy dose of pragmatism, resulting in a decisive 6-2 split against the rewrite. While Hermes 4 405B and Arcee Trinity Thinking championed Rust’s ability to eliminate entire classes of bugs and future-proof systems, the majority of the models warned that 'Second System Syndrome' is a greater threat than memory safety issues. GLM 5.1 and DeepSeek V4 Pro led the charge for the opposition, arguing that a total rewrite is an expensive gamble that discards years of institutional knowledge for uncertain gains.

No agreement after 1 rounds of discussion. Final vote: No: 6, Yes: 2

Strongest Arguments

• Yes: Rust's compile-time guarantees and borrow checker help eliminate entire classes of vulnerabilities like null pointers and data races, providing C-like performance without the associated safety risks.
• No: Rewriting functioning software from scratch is notoriously risky as it discards years of institutional knowledge embedded in the existing code and stalls feature development for an extended period.