Hacker News Reader

Comment by alilleybrinker | Hacker News Reader

Very interested in exploring how this will compare to Diesel [1] and SeaORM [2], the other two options in this space today. Joshua Mo at Shuttle did a comparison between Diesel and SeaORM in January of this year that was really interesting [3].

[1]: https://diesel.rs/

[2]: https://www.sea-ql.org/SeaORM/

[3]: https://www.shuttle.dev/blog/2024/01/16/best-orm-rust

View on HN

My first reaction is this feels like a nice middleground between Diesel and SeaORM.

The codegen part makes all columns and tables and stuff checked at compile-time (name and type) like Diesel, with a query builder that's more natural like SeaORM. I hope the query builder does not end up too magical like SQLAlchemy with its load of footguns, and stay close in spirit to Diesel that's "write sql in rust syntax".

I think time will tell, and for now I'm keeping my Diesel in production :D

Sea ORM is too opinionated in my experience. Even making migration is not trivial with their own DSL. Diesel was ok, but I never use it anymore since rocket moved to async.

I'm mainly use sqlx, it's simple to use, there's query! and query_as! macro which is good enough for most of the case.

I like sqlx, but have been eyeing diesel for some time. Any reasons you don't use diesel_async?

With Diesel async integrating everything with the pooling is a bit hairy. With sqlx everything just works.

I use SQLx, but I'm not totally convinced it's better than writing raw SQL with the underlying postgres/sqlite3/mysql driver. The macros and typing fall apart as soon as you need anything more complicated than basic a SELECT with one to one relationships, much less one/many to many.

I remember fighting with handling enums in relations for a while, and now just default to manually mapping everything.

SQLx can handle complicated queries as long as they're completely static strings. We've got SELECT FOR UPDATE, upserts, and some crazy hundred-line queries that are fine with their macros.

SQLx sucks at dynamic queries. Dynamic predicates, WHERE IN clauses, etc.

For SQLx to be much more useful, their static type checker needs to figure out how to work against these. And it needs a better query builder DSL.

Right, it's not bad if you stick with what the type checker can handle, but I usually end up falling back on manual building with the majority of queries in any semi-complex app.

It doesn't end up being too bad though, except for the loss of compile time syntax checking. Manually handling joins can be kind of nice, it's easier to see optimizations when everything is explicit.

It's nice seeing more Django/Prisma style ORMs where the non-SQL source code is the source of truth for the schema and migrations are automatically generated.

Reply on news.ycombinator.com