Item — HN Reader

It's been a while since I last had a detailed look at web applications in Rust (i.e., stuff with databases, auth, etc). You could use axum for the web server, which is very mature, but I'd say it's too low-level (IIRC you cannot even generate an OpenAPI spec of your endpoints, which IMO is table-stakes). Have you found something more batteries-included, with a similar level of maturity, and actively maintained by a community you can trust? It's a very high bar.

Your reply made me curious about ORMs, btw. Which one would you recommend? Maybe things have improved since I last checked. Last time I didn't like any of them and ended up settling on `sqlx` + hand-written SQL (the code is open source, hosted at https://github.com/rustls/rustls-bench-app/tree/main/ci-benc...).

3 comments

I love Diesel for ORMs - it's very much in the same spirit as a type safe sqlalchemy, so it depends if you like that. The type safety is a great feature, it always saves me from writing incorrect queries (a huge one is nullability is represented as an option, so nullability mismatches are caught very early). It has an async version that is not as well maintained so it does lag behind, but I've never had an issue with it. To me personally, the Diesel ORM is the #1 reason to be using Rust for a web backend - it has saved me so much pain from having db/model mismatches since they're caught early.

The only other thing I've heard that is close in any language is C#/F# LINQ (I mean I'm sure there's random other projects, but haven't talked to other people about actually deploying backends with similarly type safe ORMs other than that).

There is axum OpenAPI at https://docs.rs/axum-openapi3/latest/axum_openapi3/, I haven't personally used it, I've mostly been doing GraphQL which I find works very well (including the N+1 problem etc).

And of course, I personally find cargo and the dependencies there to be roughly as ergonomic as python. Its dependency ecosystem for web isn't as deep as python or node.js, but it's pretty solid IMO. It may not have downloadable clients for a lot of pre-existing OpenAPIs etc., but that's also something Claude can port in 5 minutes.

Upon reflection, my comfort with sqlalchemy, diesel, C++ STL, and vibe coding all share one thing in common - I am pretty comfortable liking to code at a high level that is productive, while at the same time going deep to know what the abstractions produce under the covers. E.g. I at least spot check my vibe coded code, I spot check the assembly from C++ STL to ensure zero cost abstraction, I spot check the SQL from sqlalchemy or Diesel.

I am thinking a lot of people are not comfortable with this.

Personally, super high level abstractions where I do know what ultimately results is personally what I want to be productive - so this may color my love of Rust, vibe coding, and Diesel.

Thanks for taking the time! I love being able to see through abstractions too, but for web applications I'm looking for a bit more "magic" (e.g., .NET's EF Core is the gold standard for what I'd look for in an ORM).

That's exactly why I like Diesel, it's probably the closest thing out there to EF core outside of .NET

Also curious about their opinion.

I've over the years began to interface with a lot of PHP code and there's a lot of really neat configuration stuff you can do. Ex. creating different pools for the incoming requests (so logged out users or slow pages are handled by the same pool). Like it seems to me for all of the rust web servers you have to still do a lot of stuff all on your own through code and it's not like you can create an existing Pool-ing struct.

I don't think it probably helps with a lot of the super easy stuff like creating a pool with a line of configuration - fair!

I (personally) would rather spend the fixed several hours of doing a few things like that manually, vs. pounding my head on the desk for impossible-to-find bugs.

> batteries-included

Rust tends to have more of the model of small packages that do one thing rather than monolithic frameworks.

e.g. as in the sibling comment, if you want openAPI you install axum-openapi, rather than being included in the framework.