Toasty, an async ORM for Rust

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.

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.

A good ORM is just a pre-built and externally tested validator of common DB work.

There's plenty of value in knowing both.

"AI writes amazing SQL" and "AI writes amazing DB to Application Translation Layer Code" just means "AI can write your company's bespoke ORM".

AI can give better responses to a lot of requests when it has a well designed high level API available. And many ORMs don’t produce well designed APIs but it seems this one will.

The second that you would benefit from using a DBMS specific feature, the ORM begins getting in the way. It is highly unlikely that an ORM provides support, much less a good abstraction, over features that only 1/N supported DBMS have.

Your code ends up using the driver raw in these cases, so why not just use the driver for everything? Your codebase would be consistent at that point

Has it benefited you? Have you moved to a different underlying SQL software without having to make any changes to your codebase? Or some other benefit?

I never understood why people are so stubborn about hating on orm.

For example I'm familiar with https://gorm.io and it does save me a lot of time and useless boilerplate.

And guess what, if I ever need to make a complex query, I also happen to know SQL, and I'm just going to make a "raw" query https://gorm.io/docs/sql_builder.html#Raw-SQL and be done with it.

It's not all that hard.

edit:

the other common complaint usually is: "but I don't know what query the orm is going to make..."

Use "Debug" https://gorm.io/docs/session.html#Debug and it will print out exactly what query it's making. Not happy with it? Make a raw query.

I concur. I’ve used ORMs in certain projects, but iterating and optimizing them later on became untenable. I’ve learned my lesson — all my new projects forgo ORMs by default.

A lot of people think SQL is antiquated, and therefore not worth learning. However, SQL is based upon Relation Algebra, which is the foundation of database optimalisation. Any data querying language/library that is not based on relational algebra will lack the performance. In particular ORMs fall under this category. Having said that, there are other languages/libraries out there that do use the relational algebra constructs.

Moving fast is often crucial, but you typically also get more readable code, which is also worth it.

A query/DML that is badly optimized is usually very complex, which means that the ORM's syntax isn't a good fit. No problem, since they typically support raw SQL calls, so nothing is really lost.

You just have to know when to use the right tool for the job, as always.

I respect that some prefer just to use SQL, but that isn't where most stand.

Also, instead of a reactionary "all ORMs are trash," where ORM probably means different things to different people, maybe you could provide some value to the conversation by providing specific points and/or arguments supporting your feelings about ORMs. At the very least, you could provide some citation to an article that does the summarization.

Nonsense. People use ORMs because the vast majority of queries are trivial. If you need something the ORM doesn't provide sufficient control over, only then you move to raw queries for these cases.

Yep, plus learn SQL and you can use it everywhere.

Every language has it's own (multiple) language specific ORMs.

Yeah, let's trash the 50 year old industry standard and let's obfuscate the interface to one of the most performance sensitive part of an application. Hell, lets build multiple obfuscators for each language, each with it's own astonishing behavior that turns pathological once you actually get usage on the app.