Live data from Hacker News

Our journey in dropping the ORM in Go

alanilling.medium.com

31–40 of 157 posts

Re: Our journey in dropping the ORM in Go

#31
post #7

i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.

What sort of ghoul compares a programming issue with something like the conflict in Vietnam? When he started writing about 15 million people dying you think that would have made him stop and rethink the metaphor.

This is standard fare on HN…

Just remember that HN is not Reddit, that’s the most important thing.

Re: Our journey in dropping the ORM in Go

#32

So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…

I'm shocked more people arent talking about SQLBoiler in threads like these. It solves this exact problemset. You write the SQL schema and it generates all the scan and helper functions for you. We've had a great experience with it at work after running into similar woes as OP with ORM's. https://github.com/volatiletech/sqlboiler

What are your thoughts on what the article author has to say about SQLBoiler?

Re: Our journey in dropping the ORM in Go

#33
post #7

i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.

What sort of ghoul compares a programming issue with something like the conflict in Vietnam? When he started writing about 15 million people dying you think that would have made him stop and rethink the metaphor.

This is standard fare for HN.

Just don’t mention that HN is like Reddit - that’s off limits.

Re: Our journey in dropping the ORM in Go

#34
I avoided this Vietnam completely. It was clear to me from the beginning that data model optimal for relational storage and the one optimal for internal application state (I usually write stateful servers in C++) are 2 different things.

Re: Our journey in dropping the ORM in Go

#35
post #21

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…

Went to most of the article, and it seemed to boil down to this kind of reflection:

> But as time progresses, it’s only natural that a well-trained object-oriented developer will seek to leverage inheritance in the object system, and seek ways to do the same in the relational model.

Basically, things are not perfect, and people try to blindly apply layers upon layers, thus getting deeper and deeper into a quagmire.

But the proposed solution of applying no automated layer doesn’t compute. If he can restrain himself from using any ORM at all, why can’t he restrain himself from adding inheritance in ORM models or other “let’s OOP this to death” blind approach ?

This feels like the “I sometimes get drunk so I’ll build a whole support structure to stop me from drinking”, and at no point someone steps in to say “just be moderate and it will be fine”

Re: Our journey in dropping the ORM in Go

#36

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.

ORM is that one layer that fails to abstract anything substantial yet whose existence is intrusive enough to annoy people.

The worst example of leaky abstraction.

Re: Our journey in dropping the ORM in Go

#37

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

Re: Our journey in dropping the ORM in Go

#38
post #37

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

This is the way.

ORM’s can be a huge time saver and simplify your code base for the day to day CRUD, nobody should be writing that anymore IMO.

Re: Our journey in dropping the ORM in Go

#39
post #27

The hate should be directed at SQL builder part of most ORMs. Which gets complicated pretty quickly, and it's like learning a new language when SQL works usually much better. If you write your SQL, and some tool, like code generation, then maps it to object, you are golden. It's the part you'd have to write anyway. However if the code generation goes bust (like gets abandoned like most hobby mappers), you should make…

I've been a huge fan of Slonik, https://github.com/gajus/slonik, which makes it easy and safe to write direct SQL queries. The author of Slonik had a good article about the downsides of query builders, previously discussed on HN, that I totally agree with: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...

Re: Our journey in dropping the ORM in Go

#40

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.

Post reply on HN