Why a Veteran Engineer Abandoned Rust for Speed in 2026

Rust occupies the high ground of safety and performance in the software‑engineering iron triangle, thanks to its borrow checker and strict type system that promise a world without memory errors or null‑pointer crashes.

In commercial software, however, delivery speed is a critical dimension that pure‑tech enthusiasts often overlook.

Senior engineer Dmitry Kudryavtsev published a long post titled “Farewell, Rust,” describing why he rewrote a profitable Rust web project in Node.js, sparking a deep debate about whether extreme safety justifies sacrificing delivery speed.

Origin: a C/C++ veteran’s safety dream

Dmitry’s background is rooted in hardcore C/C++ development; he loved low‑level memory control and resented the security bugs common in C. After early work with PHP, Python, and Ruby, he discovered Rust, which seemed to offer “the best of both worlds.”

Low‑level control comparable to C.

Safety through compile‑time elimination of whole classes of memory errors.

Modern tooling such as Cargo.

He built a commercial web application from scratch in Rust, launched it at the end of 2023, and gave talks at two technical conferences. Over time, growing business logic turned the safety dividend into a delivery‑speed loss, and by early 2026 he decided to say goodbye to Rust.

Deep dive: Five speed killers in Rust web delivery

1. Templates and views: type safety vs. iteration speed

Compile‑time template libraries like Maud and Askama enforce variable correctness, but any HTML change triggers a full recompilation, which is disastrous for rapid UI iteration.

Node.js with TypeScript + JSX/TSX provides full‑stack type safety and instant hot‑reload, allowing UI changes to appear in milliseconds.

2. Internationalization (i18n): ecosystem gap

Rust lacks mature, out‑of‑the‑box i18n solutions; developers must write extensive glue code and handle type bindings manually. In contrast, Node.js libraries such as i18next and the built‑in Intl API deliver ready‑made, type‑safe internationalization, saving weeks of effort.

3. Dynamic business vs. static constraints

Serialization pain: using serde with Option<T> forces developers to write many match or unwrap statements and dozens of custom error enums, slowing development.

SQL dead‑end: sqlx offers powerful compile‑time checks, but building dynamic queries becomes a nightmare compared with Node.js libraries like Kysely or Prisma.

4. Compile time: CI/CD hidden killer

Rust builds with many macros can take 12–14 minutes in CI, making bug fixes feel costly. After migrating to Node.js, the full CI pipeline (including lint and tests) dropped to about 5 minutes, cutting the feedback loop threefold.

5. Ecosystem maturity: reinventing the wheel

For niche third‑party services or webhook signatures, Rust often lacks official SDKs; developers must hand‑write HTTP requests and cryptographic verification, consuming significant time. Node.js typically resolves such needs with a single npm install of a maintained SDK.

Conclusion and reflection

Dmitry still values Rust’s safety and low memory footprint—Rust applications use 60–80 MB versus Node.js’s ~117 MB, a 50 MB difference that costs only a few dollars per month in cloud hosting. However, the extra development time, debugging effort, and mental load outweigh the savings for typical business applications.

He proposes a “golden rule” for technology selection:

Embrace safety (choose Rust) when building database engines, search systems, high‑frequency trading platforms, embedded firmware, or cold‑start‑sensitive serverless functions where performance and stability are core.

Embrace delivery speed (choose Node.js, Go, or Python) for CRUD back‑ends, SaaS logic, internal tools, or early‑stage startups that need rapid iteration and frequent requirement changes.

He notes that Go may occupy a “golden balance point,” offering static compilation and type safety with faster compile times, simple syntax, and a mature middleware ecosystem.

The overall message is that no language is universally superior; teams must balance safety against delivery speed based on the specific constraints of their projects.