On: Show HN: Cot: a Rust web framework for lazy develo...

[mathw]

I've yet to see an ORM which doesn't just eventually make everything harder. Especially when it comes to automatic migrations, which seldom seem to take into account production necessities like multi-node deployment, downtime considerations and not destroying your production data silently because it doesn't fit.

[submain → mathw]

ORMs are one of those things that make sense for really tiny projects but fail to scale once complexity settles in.

[iterateoften → submain]

Exact opposite experience.

“SQL strings are one of those things that make sense for really tiny projects but fail to scale once complexity settles in“

Large projects require reuse, composability and easy refactoring. All things ORMs excel at.

On a small code base it is easy to rename a column or add a column, etc.

On a large code base with already 100s of queries using that table, without an ORM it isn’t as straightforward to update all references and ensure that ever place consuming that table has the new column info.

[submain → iterateoften]

Type checking is indeed an advantage of ORMs. You pay for it with object relational impedance mismatch. That impedance grows as your schema grows.

In my experience, the way to get the best of both worlds is to use a query builder as opposed to a full ORM.

[iterateoften → mathw]

> like multi-node deployment, downtime considerations

Never had an issue with Django on a large project at a previous $8b startup whose code base went over several major data refactors.

In fact Django’s excellent migrations was specially called out for the reason for our confidence in making large DB refactors.