[echelon]

Rust ORMs still don't feel great. They're verbose, the tooling is flaky, and they feel fly-by-night. They're surprisingly not very type safe either. I'd rather use Rust's sqlx until the Rust ORM situation improves.

Axum and Actix are already drop in replacements for something like Flask. They're mature and good at what they do.

The dream of a Rails or Django in Rust is still really far off. I'm glad the Loco folks are trying, but it needs a lot more magic and maturity to truly bear that comparison.

[Spartan-S63]

Back when SeaORM first released, I was excited about another ORM that supported async (as Diesel didn't have an async shim at the time), but man does it have some weird design decisions.

The underlying query builder's API is just downright odd. The ActiveRecord pattern is fine for SeaORM, but it's just... weird. The ergonomics aren't right.

It's sent me down the path of wanting to design an ORM for myself that has the ergonomics I want. Nothing really to show yet at this point, but still something I want to build out someday.

[Jalad]

Can you please explain what you found weird? I just started using sea-query and haven't found anything super odd quite yet, but I've only written a few migrations and queries so far

[Spartan-S63]

Namely, it comes from their query builder's API choices. For example, from SeaQuery's README:

```

use sea_query::*;

// For example Character table with column id, character, font_size... pub enum Character { Table, Id, FontId, FontSize, }

// Mapping between Enum variant and its corresponding string value impl Iden for Character { fn unquoted(&self, s: &mut dyn std::fmt::Write) { write!( s, "{}", match self { Self::Table => "character", Self::Id => "id", Self::FontId => "font_id", Self::FontSize => "font_size", } ) .unwrap(); } }

```

The idea that the `Table` is part of the `enum` is an odd choice to me. The `Iden` trait also has an odd shape and use to me, as well.

In theory, the API for SeaORM is something I like, but in practice it feels off and stilted. Still a really cool project and I hope things improve over time, but Rust is going through a lot of growing pains around ORMs and database access.

[mattrighetti]

I can say a word or two about sea-query.

I've used it for 3-4 months in a lot of my projects. For very basic queries it worked very well and I liked it quite a bit, but as soon as I had to do something a little less standard that's where I started to see the issues.

Documentation is not really there yet and I ended up loosing tons of time trying to look for the right function in the crate that would translate in the query I had to make. I've blogged about that too if you're interested [0] (TLDR: I got back to using raw SQL)

[0]: https://mattrighetti.com/2025/01/14/ditching-sea-query

[dgroshev]

I don't think "glue" frameworks like Loco can get us there tbh. One problem is that frameworks like Django or RoR have to be tightly integrated! Auth needs to be aware of models and sessions, autogenerated admin pages like Django have to rely on model metadata, templates and view code might need to be aware of cache busting and static file handling, etc etc. It's a tough problem and a very high barrier to creating a new comprehensive framework.

[jtwaleson]

I'm using Loco a lot since half a year, and have contributed some upstream patches. It's definitely not Rails, but where I was always afraid of refactoring Python applications, that fear is pretty much gone with Loco/Rust. That, and the incredible performance make me enjoy it a lot now. You pay extra with development time, but you get it back with long term maintainability.

My main remaining gripe is the Rust compilation speed...

[tonyhart7]

wdym magic, its rust

there is no magic only a lot of macros, and someone must write them

if you talking about mature, of course 20+ years web framework is more mature + have more feature than loco. what kinda comparison is that