Live data from Hacker News

Show HN: Cot: a Rust web framework for lazy developers

mackow.ski

61–70 of 115 posts

Re: Show HN: Cot: a Rust web framework for lazy developers

#62
post #50

Earlier quoted context omitted.

> Also, don’t use an ORM. Just write that SQL. Your future self will be thankful. I have never understood this. I've been using the ORM for twenty years now, it's saved me countless hours, and I've very rarely needed to break out of it. When I did, I just wrote an SQL query, and that was it. What's the big deal?

It depends on the ORM. I've definitely seen a couple (popular, even) where it's worse than nothing at all, if you're comfortable in SQL. But most of them I'd agree, they're handy. I think some of the blanket "just don't" comes from people who've had to onboard to projects written by teams that didn't understand SQL, but did (sort of) know how to use an ORM, and blame the ORM for allowing those teams to commit their a…

Ah yeah, my experience is with the Django ORM, with which I've had nothing but good experiences with.

Re: Show HN: Cot: a Rust web framework for lazy developers

#63
post #37
post #18

Earlier quoted context omitted.

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.

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

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.

Re: Show HN: Cot: a Rust web framework for lazy developers

#64
post #2

> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…

I never worked with Rust, but maybe the complexity is due to how the language works.

Using Django's ORM, that would simply be: link=Link.objects.get(slug="cot")

It'd still be very readable and manageable even for complex queries.

Re: Show HN: Cot: a Rust web framework for lazy developers

#65
post #18
post #2

> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…

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.

> 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.

Re: Show HN: Cot: a Rust web framework for lazy developers

#66
post #42

I think Django's marketing for perfectionists with deadlines is a bit better than "for lazy developers" :) but excited to see people build "Django, but compiled"

Naah it's perfectly good marketing: "for lazy developers" is way more catchy than "for perfectionists". Look how we discuss that.

Re: Show HN: Cot: a Rust web framework for lazy developers

#67
post #24

Earlier quoted context omitted.

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 mu…

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 e…

I am confident in easy SELECT queries, even with multiple tables, but once i have to use JOIN or other advanced things my queries are a mess, returning data i never expected.

Re: Show HN: Cot: a Rust web framework for lazy developers

#68
post #50
post #35

Frameworks that do “everything” are not a good idea. I’m from the Java ecosystem. Spring is the “batteries included” framework there. If you have migrated any real world application to a new major version once, you’ve learned forever that “all in one” frameworks are bad. Please don’t do it! Instead, use scaffolding tools, that give you a head start on creating a new project, using smaller, specialized libs. Also, don…

> Also, don’t use an ORM. Just write that SQL. Your future self will be thankful. I have never understood this. I've been using the ORM for twenty years now, it's saved me countless hours, and I've very rarely needed to break out of it. When I did, I just wrote an SQL query, and that was it. What's the big deal?

This depends very much on the size of the code base, the amount of data in the DB and (of course) the quality of the ORM.

It sounds like you are lucky enough that you have never had an ORM generating badly optimised/n+1/over-eager queries that take down a production service. Or perhaps had to debug low level query cache issues causing unexpected problems.

I'm not advocating for plain SQL, just offering some suggestions as to why someone might want you to consider it.

Post reply on HN