Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our journey in dropping the ORM in Go

alanilling.medium.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Our journey in dropping the ORM in Go

#71

Post by the_af »

nauticacom wrote: post #66
the_af wrote: post #21

Earlier quoted context omitted.

> Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself This is addressed in the article the title of this one refers to, "The Vietnam of Computer Science" [1]. I really recommend reading it in order to understand why the "obvious" solution is not always the best fit, but the very short summary is: due to the Object-Relational Impedance Misma…

It's no wonder this article was written in 2006. One of the problems describes DBAs ! Has anyone heard of a DBA in the last decade? Most of these other problems are just... solved? Any decent language will let you override the meaning of equality between two objects, if you don't use a ton of inheritance the inheritance problem won't bite you, good libraries let you describe the schema once and either generate SQL or…

Two years ago I worked at a company with a DBA team. In my current job, there are no database experts and people don't understand things like indexes.

In my experience, most developers don't understand databases (of any kind).

So I'd say none of the problems from that article are really solved.

Re: Our journey in dropping the ORM in Go

#73

Post by brodo »

GordonS wrote: post #37
kevmo314 wrote: post #24

As a junior dev I had no idea what an ORM was. As a mid-level dev I discovered them and wanted to use them everywhere. As a senior dev I've gone back to manually writing queries. Such is life.

And when you eventually ascend to true mastery, you'll be able to enter a zen-like trance, in which you'll be able to tell when to use one or not, or indeed whether to use both (e.g. ORM for simple CRUD stuff, hand-written queries for everything else).

The problem is that most apps start out as simple CRUD apps. Also each dependency is a liability. People really underestimate how pulling in dependencies can lower your software quality. Most people have security bugs in mind, but there are also performance issues, memory leaks and logging-issues, needles abstractions and incompatibilities.

Re: Our journey in dropping the ORM in Go

#75

Post by avgcorrection »

the_af wrote: post #21
nauticacom wrote: post #5

Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself

> Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself This is addressed in the article the title of this one refers to, "The Vietnam of Computer Science" [1]. I really recommend reading it in order to understand why the "obvious" solution is not always the best fit, but the very short summary is: due to the Object-Relational Impedance Misma…

Maybe the original author never read Chomsky.

https://chomsky.info/198210__/

Re: Our journey in dropping the ORM in Go

#76

Post by m0zg »

kevmo314 wrote: post #24

As a junior dev I had no idea what an ORM was. As a mid-level dev I discovered them and wanted to use them everywhere. As a senior dev I've gone back to manually writing queries. Such is life.

Real fun begins if your team has all three stages of seniority. Typically it's somewhere in the middle, so your default is to use ORM, even though as a senior person you know everyone will profoundly regret this in the long run (and you will regret it immediately).

Re: Our journey in dropping the ORM in Go

#77

Post by drran »

karmasimida wrote: post #40
nauticacom wrote: post #5

Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself

Is writing SQL query templates too much? The only valid advantage of ORM is to prevent SQL injection, which can be solved with prepared statement.

My compiler cannot type check SQL code, so I need to run SQL to check it correctness. It's the same problem as with JavaScript, Python, Perl, shell, etc.

For JavaScript, the problem is solved (partially) with TypeScript.

Re: Our journey in dropping the ORM in Go

#78

Post by languagehacker »

We will never be able to separate this fine argument from the fact that gorm has been terribly immature for quite some time. ORMs take a long time to grow. Look at Arel and ActiveRecord. Sufficiently mature ORMs provide addordances to work around the fundamental N+1 and abstraction issues that always crop up, but they take time, dedication, and a broad community. Go is an interesting case in which there are enough useful applications that don't comprise "web apps" that we might not be in at the point of ORM maturity. I've used both gorm and go pg, and have definitely encountered frustrating limitations coming from both ends of the problem.

Re: Our journey in dropping the ORM in Go

#79

Post by VWWHFSfQ »

kevmo314 wrote: post #24

As a junior dev I had no idea what an ORM was. As a mid-level dev I discovered them and wanted to use them everywhere. As a senior dev I've gone back to manually writing queries. Such is life.

As with everything, it really depends on what you're doing. Do I want to implement an entire CMS and core business backend directly in SQL? No, of course I don't. I want to use Django's ORM because then I get all the nice QuerySet API, integrations with forms and filters, the nice Admin UI, etc.

But do I want my end-users to hit my Django ORM APIs 10,000 times per second? Absolutely not. So you write hand-optimized SQL for those and maybe run them in a service a little bit faster than Python/Django/Gunicorn.

It's the same database, it's the same "API". But you get the value of everything that Django's ORM provides and you just cheat a little bit by dropping down to the lower level for things that need it, and not everything needs it.

Don't throw out the baby with the bath water!

Re: Our journey in dropping the ORM in Go

#80

Post by devoutsalsa »

cageface wrote: post #70
toast0 wrote: post #52

Earlier quoted context omitted.

ORM makes the easy things easier and the hard things harder. No thanks.

So choose an ORM that lets you easily drop down to plain SQL in the rare cases where it's necessary and you get the best of both worlds.

100%. You don’t have to trash your 5 passenger car because you occasionally need to transport 6 people.
Post reply on HN