Rust needs a web framework
Rust’s growing popularity has renewed calls for a “batteries‑included” web framework comparable to Rails, Django, or Laravel, aimed at developers who want to ship web apps quickly without stitching together many small crates. Commenters point out that Rust already has capable web libraries and frameworks (Axum, Actix, Rocket, Loco, Poem, Shuttle), but none with the integrated, opinionated experience and large contributor base of the major full‑stack frameworks in other languages. The thread also probes whether Rust is even a good fit for most web work—given alternatives like Go, Elixir/Phoenix, Java/.NET, or classic scripting stacks—versus where its type system, performance, and single‑binary deployment genuinely justify the added complexity.
Existing Rust web ecosystem
- Multiple web frameworks already exist: Actix-web, Axum, Rocket, Poem, Loco, Shuttle, “Rust on Rails”‑style projects, and Spring-like efforts (spring-rs).
- Some commenters say these already cover routing, middleware, templates (e.g., minijinja, liquid-rust), static files, DB access (Diesel, sqlx), auth via OIDC, caching (Redis), observability, and background workers.
- Others note these are more like Flask/FastAPI/Express: powerful but not integrated “batteries‑included” systems.
Demand for a Rails/Django‑style framework
- Many want a single, opinionated, full‑stack framework for “lazy/efficient” devs: routing, auth, permissions, templating, admin, ORM, caching, monitoring, asset bundling, deployment tooling.
- The key desire is curated, well‑integrated defaults so you don’t spend days picking crates and wiring plumbing for every new project.
- Some argue this is analogous to Rails, Django, Laravel, Phoenix, ASP.NET Core, Laravel, Laravel, etc., which are praised for speed of building CRUD apps and good defaults.
Skepticism about a big Rust framework
- Several point out that Rails‑like clones in other languages rarely gain traction; successful frameworks tend to be extracted from large production apps over time.
- Concerns: small maintainer bases, long‑term governance, release limbo (Rocket cited), and the risk of betting on a one‑person project for core infrastructure.
- Some prefer the current “pile of libraries” for flexibility and avoiding accidental complexity.
Is Rust a good web language?
- Critics say Rust’s complexity, async model, and ownership rules are overkill for typical IO‑bound web apps where DB/network is the bottleneck; GC languages and existing frameworks (Django, Rails, Laravel, Phoenix, ASP.NET, Go, JVM/.NET stacks) are seen as more productive.
- Supporters argue Rust web dev is already comparable in effort to Go/Java, while offering: strong types, enums/ADTs, trait‑based abstraction, fearless concurrency, good tooling (cargo, error messages), and single static binaries for deployment.
- Some justify Rust simply because they enjoy it; for hobby projects “wanting to use Rust” is treated as sufficient.
Laziness, productivity, and ergonomics
- “Lazy developer” is debated: some equate it with using GC and high‑level frameworks; others with offloading correctness to a strong type system and compiler.
- A common theme: Rust’s types and compiler make refactors and long‑term maintenance easier, even if initial coding is slower.
- Others note that for quick prototypes and early‑stage exploration, dynamic or GC languages often feel less constraining.