Hacker News Reader

Comment by qes | Hacker News Reader

> I’m shocked at how many people have issues with ORMs

Simple inexperience. I'd bet most of those people are mid-level developers who have used ORMs enough to hit the rough edges but not enough, or with enough independent agency, to have worked through how to play to ORM's strengths while avoiding their weaknesses. People that were given a hammer and are just understanding that their hammer doesn't work very well to install bolts, and maybe don't have the authority to say maybe I should use a wrench or the flexibility to try this new crescent shaped idea and see if that works better.

View on HN

Or maybe you worked only on “toy” projects and never understood that you are doing more work that could be expressed more elegantly in a functional SQL expression instead of using the imperative statements of the ORM engine? The craziest thing in this discussion is that I have to defend SQL that is probably my least favourite language... I never expected this honestly.

My "toy" project with several hundred tables and tens of thousands of users does fine.

I have, at most, a couple dozen "complex" queries in this project.

Whereas I have an order of magnitude more queries that need to be composed from several different query criteria, a task for which SQL is very poorly optimized for and most ORMs excel at.

I have used my ORM for so long that writing a report in SQL or the ORM language is basically the same to me. Neither technology is something I would consider to be "hard", as most of the problems encountered in practice are well-trodden.

Nontheless, a simple ORM query is 20% the length of an equivalent SQL query. And I can compose them trivially. And then I use the model code for the _hard_ part: dealing with the rest of the business logic for template rendering, email sending, API interactions, and so on, for which SQL is completely useless.

Your "toy project" doesn't have 10+ team members, ranging in experience.

Yes it does.

Seriously using an ORM is just not hard. Especially if actually do code reviews with your junior team members, which you should always be doing.

Reality does seem to paint a very specific picture.. Django; ORM. Rails; ORM.. I think just about every super popular framework either created or has official support for an ORM. Most popular language platforms have a descent enough ORM options. Phoenix? Let's just call Ecto an ORM.

Thinking about projects I'm aware of.. Stack Overflow created an ORM regardless of if they call it "Micro". They created it and people use it. GitLab uses ActiveRecord.. Gogs and Gitea use ORMs that are a bit fringe TBH.. I actually can't think of a large project I've touched that went completely raw dog on the SQL.

I do believe there are instances where using an ORM, or at least all of an ORM, is not the best choice. But to come out and say they should always be avoided? It's interesting how many people are coming in here SO SURE about that position that is seems completely at odds with what the rest of the industry is, objectively, doing. And when pressed their insights into that opinion are so shallow a baby couldn't drown in them. Hmmm.

It's condescending and convenient for you to discount the people who disagree with you as merely inexperienced.

You could level the same empty claim at people who like ORMs: I loved ORMs when I was a beginner but learned it's best to avoid them as I accumulated experience. So anyone who likes ORMs is merely in that beginner stage.

Just not true.

And regardless, why should we develop things that only "experienced devs" can work with without blowing a hole in their face? Junior and intermediate devs are often in larger projects.

Reply on news.ycombinator.com