Writing raw SQL is perhaps indeed easier for simple queries, but put some foreign keys inside or slightly more complex relationships between tables and you'll probably quickly fall into the trap of having to remember your entire database schema to write anything. Yes, the example from the documentation is slightly more complicated, but it checks at compile time the exact column names and types, so you get feedback much quicker than actually running the SQL query.

In addition to that, over the years of writing web services, I always found raw queries much less maintainable. The ORM immediately tells you that you messed up your refactoring, whether it is just renaming a column, or removing a table completely.

Pretty much every ORM (including the one in Cot) also allows you to write your own custom queries if the abstractions are not enough, so there's always this fallback option.

> Yes, the example from the documentation is slightly more complicated, but it checks at compile time the exact column names and types, so you get feedback much quicker than actually running the SQL query.

Well sqlx checks at compile time your raw query if you use their macro, at the expense of increased compile times.

I never understood the hate against ORMs. It always seems like a superiority complex or some claim that SQL is “so simple”.

Yeah SQL is extremely simple to write, that isn’t really the problem ORMs solve for me, but rather they solve composability and reuse of queries.

I think there is a similar vein of people crying about sites not using 100% vanilla js without a framework. They are missing the point or don’t have enough experience with the actual problems the abstractions solve.