Source linked

Rust Web Dev's Dirty Secrets: Backtraces de 100 frames, Binaries de 37 Mo

blog.jetbrains.com@vast_falcon4 hours ago·Developer Tools·5 comments

La sécurité et les performances de Rust sont coûteuses : les traces de dépannage sont inutiles, les ORM nécessitent une maintenance triple du schéma et compilent des ballons de temps à 37 Mo.

rustweb developmentasync rustdieselaxumcot rs

A single panic! in async Rust can produce a 100-frame backtrace where your actual bug hides between frames 9 and 10. That's not a bug report - that's a codebase telling you its debugging story isn't ready for prime time.

Async's Debugging Tax

Rust's async model is technically brilliant, but the developer experience hasn't caught up. You need to understand both async fn and how to implement Future yourself - they're different enough to feel like learning two separate things. Mix threads and tasks with the wrong data structures, and you get deadlocks. Stable Rust still lacks async drop. And pinning? That's its own rabbit hole.

The real pain shows up when you try to debug. When an async function yields, execution returns to the runtime; when it resumes, the backtrace resets. The result: a 100-frame stack dump with runtime machinery filling 90 frames and your actual logic buried where only a forensic archaeologist would find it. Technically correct. Practically useless.

Triple Schema Maintenance

Database access is another place where Rust asks for repeated work. In Diesel, you define your model in Rust, write SQL migrations, and maintain an auto-generated schema.rs file. Three representations of the same data. SeaORM improves some ergonomics but still feels like SQL with Rust syntax glued on top.

Compare Django's approach - you define your model once, migrations are implicit - against Rust's current state, where you're essentially writing the same thing in three slightly different languages. Projects like cot.rs are experimenting with declarative migrations that represent schema changes as structured operations rather than raw SQL. Toasty and rorm are exploring similar directions. The goal isn't magic; it's stopping the repetition.

Error Handling's Consistency Trap

Rust makes errors explicit, but making them consistent across a web application is harder than it looks. Axum has two mechanisms - IntoResponse and HandleErrorLayer - and new users don't know which to pick. IntoResponse requires implementing it for every error type, so different libraries return different response shapes. Actix-web's ResponseError trait is cleaner but lacks access to broader request context. Middleware that consumes the request (common in tower-http) means error handlers lose the context they need.

Macro Magic and Compile-Time Bloat

Macros are everywhere in Rust web frameworks: routing, serialization, extractors, database queries. When they work, they're great. When they fail, you're reading thousands of lines of generated code. Error messages point inside generated code rather than at your actual mistake. IDE support for proc macros is uneven.

And then there's the binary size cost. Generics combined with macros can push a release binary from 2MB to 37MB - monomorphization at scale. One documented analysis found expand_crate taking 67.5% of total compile time in a macro-heavy SQLx project. Compile-time SQL verification is useful, but it comes with a real time cost.

Ecosystem Fragmentation

Starting a Rust web project means assembling your own stack: web framework, database layer, migration tool, templating engine, frontend integration, authentication. Each piece has multiple options, and they don't always compose cleanly. arewewebyet.org hasn't been updated in five years, but its point still holds: Rust has no dominant batteries-included framework at Django or Rails level. Most frameworks are closer to Flask or Sinatra - powerful for experienced developers, overwhelming for everyone else.

Batteries-included frameworks like Loco.rs (already in production) and cot.rs (still maturing) are trying to close the gap. They won't make async debugging, compile times, or macro complexity disappear. But a more coherent starting point removes at least some of the repeated work that comes before the actual application.

Rust web development in 2026 is better than ever, but it still demands you accept a slower feedback loop and a deeper understanding of every layer. If your bugs are expensive - and they often are - the tradeoff is worth it. Just know what you're signing up for before the first cargo build.


Source: The Unglamorous Side of Rust Web Development
Domain: blog.jetbrains.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.