1. 14
  1. 18

    I once gave a talk about what makes a successful abstraction layer and evaluating ORMs as an abstraction layer (similar to the pros and cons in this blogpost).

    I think what makes ORMs more popular than they probably should be is that the benefits are front-loaded while the drawbacks appear when you’ve already invested considerable amount of effort into working with one.

    Long story short, I consider ORMs a flawed abstraction layer because they make things more opaque (performance, data representation that you actually care about), coupled to a framework/library (it inevitably happens that once a project starts using an ORM you have a hard time understanding meaning in data without always using those classes describing your data, in effect binding you to that ORM), and when inevitably you end up needing to understand and work with SQL anyway in some cases, you end up with Claw crane syndrome: ever tried using one of these to get your prize instead of just using your hands? Yeah, ORMs feel a lot like that sometimes.

    When you have a small application/service/project with a single programming language (and one of the better ORMs), where you don’t mind that the data/performance/object model is strongly fused together, then it’s an okay choice. For anything else, it might be more painful.

    SQL itself in comparison is probably a much better abstraction layer, even with it’s own imperfections.

    1. 9

      I think what makes ORMs more popular than they probably should be is that the benefits are front-loaded while the drawbacks appear when you’ve already invested considerable amount of effort into working with one.

      This has been my experience with every ORM I’ve come across. The time/effort savings is an illusion, and (in my experience) by the time that illusion fades you’ll never get the time to factor the ORM out of your project. I got so frustrated working on a Scala project that uses Slick recently, I did a little write-up.

      1. 3

        I find this quite interesting. A year or two ago, I decided to investigate all database wrappers in different languages that seemed better than a regular ORM, and Slick was one that seemed (for a while) to me to get things right. (Although Quill looked even better.) But in the end I came to the conclusion that all but the thinnest wrappers are a waste of time in general, and I’ve increasingly taken a database-centric approach, using SQL and the database’s capabilities to the fullest extent without wrapping them up in layers of poorer abstractions.

    2. 4

      I think sqlx lets you use raw sql, but scan directly into go structs. Better than both approaches in my opinion.

      1. 1

        Slick (Scala library) does many things right <3

        1. 0

          I think in Go both options are painful.