18 ms·

Honestly so many things profit from generics, e.g. ORM code was very awkward before especially when returning slices of objects as everything was []any. Now you

Honestly so many things profit from generics, e.g. ORM code was very awkward before especially when returning slices of objects as everything was []any. Now you can say var users []User = orm.Get[User](…) as opposed to e.g var users []any = orm.Get(&User{}, …), that alone is incredibly useful and reduces boilerplate by a ton.

vbezhenar 2y ago
ORM is anti-pattern and reducing boilerplate is bad.
- makapuf 2y ago
  I agree. The best language to handle data in a RDBMs is SQL, and in that case the best language to handle application logic is Go (or Kotlin, Python or whatever). So there must be some meeting point. Handling everything in Go is not optimal, and all in sql not always practical. So how to avoid redundant data description ? I often have structs in a model Go file that reflect queries I do, but that's not optimal since I tend to have to repeat what's in a query to the language and the query to struct gathering is often boilerplate. I also almost can reuse the info I need for a query for another query but leave some fields blank since they're not needed.. the approaches are not optimal. Maybe a codegen sql to result structs / gathering info ?
- bluesnews 2y ago
  Could you expand on this? I don't like ORM because in my experience you inevitably want full SQL features at some point but not sure if you have the same issues in mind or not
  - vbezhenar 2y ago
    ORM is for object-relation mapping. Go is not object-oriented language and OOP-patterns are not idiomatic Go, so using ORM for Go cannot be idiomatic. That's generic answer. As for more concrete points: 1. Mapping SQL response to maps/structs or mapping maps/structs to SQL parameters might be useful, but that's rather trivial functionality and probably doesn't qualify as ORM. Things get harder when we're talking about complex joins and structs with relationships, but still manageable. 2. Introducing intermediate language which is converted to SQL is bad. Inevitably it will have less features. It will stay in the way for query optimisations. It'll make things much less obvious, as you would need to understand not only SQL, but also the process of translating intermediate language to SQL. 3. Automatic caching is bad. Database has its own caching and if that's not enough, application can implement custom caching where it makes sense. In my opinion the only worthy database integration could be implemented with full language support. So far I only saw it with C# LINQ or with database-first languages (PL/SQL, etc). C# and Go are like on opposite spectrum of language design, so those who use Go probably should keep its approach by writing simple, verbose and obvious code.
    - indulona 2y ago
      > Go is not object-oriented language That is most definitely not true. Go just uses composition instead of inheritance. Still OOP, just the data flow is reversed from bottom to the top.
      - deleted 2y ago
        [deleted]
      - nordsieck 2y ago
        >> Go is not object-oriented language > That is most definitely not true. I think at best, you could say that Go is a multi-paradigm language. It's possible to write Go in an object oriented style. It's also possible to write programs with no methods at all (although you'd probably have to call methods from the standard library). That's in contrast to a language like Java or Ruby where it's actually impossible to avoid creating objects.
        pjmlp 2y ago
        Unless you happen to want to warm up the CPU, there is very little Go code that is possible to write that does anything useful without OOP concepts, like interfaces, methods and dynamic dispatch. Creating objects on the heap isn't the only defining feature how a language does OOP or not.
      - randomdata 2y ago
        Go has objects, but objects alone does not imply orientation. For that, you need message passing.
      - frou_dh 2y ago
        It goes like this: 1. Software development is a fashion industry. 2. OOP is currently uncool. 3. People who identify as Go programmers don’t want it to be thought of as connected to OOP at all, because then it is uncool by association.
    - kgeist 2y ago
      I find libraries like sqlx more than enough. Instead of a full-blown ORM, they simply help hydrate Go structs from returned SQL data, reducing boilerplate. I prefer the repository pattern, where a repository is responsible for retrieving data from storage (using sqlx) using simple, clean code. Often, projects which use full-blown ORMs, tend to equate SQL table = business object (aka ActiveRecord) which leads to lots of problems. Business logic should be completely decoupled from underlying storage, which is an implementation detail. But more often than not, ORM idiosyncracies end up leaking inside business logic all over the place. As for complex joins and what not, CQRS can be an answer. For read queries, you can write complex raw SQL queries and simply hydrate the results into lightweight structs, without having to construct business objects at all (i.e. no need for object-relational mapping in the first place). Stuff like aggregated results, etc. Such structs can be ad hoc, for very specific use cases, and they are easy to maintain and are very fast (no N+1 problems, etc). With projects like sqlx, it's a matter of defining an additional struct and making a Select call.
- TheDong 2y ago
  > reducing boilerplate is bad Programming is about building abstractions, abstractions are a way to reduce boilerplate. Why do we need `func x(/* args / ) { / body */ }`, when you can just inline the function at each callsite and only have a single main function? Functions are simply a way to reduce boilerplate by deduplicating and naming code. If 'reducing boilerplate is bad', then functions are bad, and practically any abstraction is bad. In my opinion, "reducing boilerplate is bad in some scenarios where it leads to a worse abstraction than the boilerplate-ful code would lead to". I think you have to evaluate those things on a case-by-case basis, and some ORMs make sense for some use-cases, where they provide a coherent abstraction that reduces boilerplate... and sometimes they reduce boilerplate, but lead to a poor abstraction which requires more code to fight around it.
- bobnamob 2y ago
  Not liking ORM I can understand, db table <-> object impedance mismatch is real, but "reducing boilerplate is bad" is an interesting take. Can you elaborate and give some examples of why reducing boilerplate is generally "bad"?
  - rad_gruchalski 2y ago
    Not the person you’re replying to. The orm sucks because as soon as you go out of the beaten path of your average select/insert/update/delete, you are inevitably going to end up writing raw sql strings. Two cases in point: postgres cte and jsonb queries, there are no facilities in gorm for those, you will be just shoving raw sql into gorm. You might as well stop pretending. There’s a difference between having something writing the sql and mapping results into structs. The latter one can be done with the stdlib sql package and doesn’t require an „orm”. There are two things an sql lib must do to be very useful: prepared statements and mapping results. That’s enough.
    - bobnamob 2y ago
      You haven’t answered my question at all. The parent comment made two claims: ORM not great (I agree) and “boilerplate reduction bad” which still needs some elaboration
      - rad_gruchalski 2y ago
        I answered it, you just don’t see it. One ends up with the boilerplate anyway as soon as one attempts to step out of the usual crud path. There’s no gain, there’s no difference in templating an sql string vs fighting an orm api.
    - metaltyphoon 2y ago
      Perhaps you have to yet use a good ORM? I could probably count on my fingers the times I had to drop to raw SQL in EFCore. Even when you do that you can still have mapped results, which reduces boilerplate.
- deleted 2y ago
  [deleted]
indulona 2y ago
understandable. thee are always valid uses cases. although ORM in Go is not something that is widely used.
the_gipsy 2y ago
gorm just takes a pointer of your type and does reflection magic. It's worse than generica, I agree, but you don't get []any.

vbezhenar 2y ago

ORM is anti-pattern and reducing boilerplate is bad.

makapuf 2y ago
I agree. The best language to handle data in a RDBMs is SQL, and in that case the best language to handle application logic is Go (or Kotlin, Python or whatever). So there must be some meeting point. Handling everything in Go is not optimal, and all in sql not always practical. So how to avoid redundant data description ? I often have structs in a model Go file that reflect queries I do, but that's not optimal since I tend to have to repeat what's in a query to the language and the query to struct gathering is often boilerplate. I also almost can reuse the info I need for a query for another query but leave some fields blank since they're not needed.. the approaches are not optimal. Maybe a codegen sql to result structs / gathering info ?
bluesnews 2y ago
Could you expand on this? I don't like ORM because in my experience you inevitably want full SQL features at some point but not sure if you have the same issues in mind or not
- vbezhenar 2y ago
  ORM is for object-relation mapping. Go is not object-oriented language and OOP-patterns are not idiomatic Go, so using ORM for Go cannot be idiomatic. That's generic answer. As for more concrete points: 1. Mapping SQL response to maps/structs or mapping maps/structs to SQL parameters might be useful, but that's rather trivial functionality and probably doesn't qualify as ORM. Things get harder when we're talking about complex joins and structs with relationships, but still manageable. 2. Introducing intermediate language which is converted to SQL is bad. Inevitably it will have less features. It will stay in the way for query optimisations. It'll make things much less obvious, as you would need to understand not only SQL, but also the process of translating intermediate language to SQL. 3. Automatic caching is bad. Database has its own caching and if that's not enough, application can implement custom caching where it makes sense. In my opinion the only worthy database integration could be implemented with full language support. So far I only saw it with C# LINQ or with database-first languages (PL/SQL, etc). C# and Go are like on opposite spectrum of language design, so those who use Go probably should keep its approach by writing simple, verbose and obvious code.
  - indulona 2y ago
    > Go is not object-oriented language That is most definitely not true. Go just uses composition instead of inheritance. Still OOP, just the data flow is reversed from bottom to the top.
    - deleted 2y ago
      [deleted]
    - nordsieck 2y ago
      >> Go is not object-oriented language > That is most definitely not true. I think at best, you could say that Go is a multi-paradigm language. It's possible to write Go in an object oriented style. It's also possible to write programs with no methods at all (although you'd probably have to call methods from the standard library). That's in contrast to a language like Java or Ruby where it's actually impossible to avoid creating objects.
      - pjmlp 2y ago
        Unless you happen to want to warm up the CPU, there is very little Go code that is possible to write that does anything useful without OOP concepts, like interfaces, methods and dynamic dispatch. Creating objects on the heap isn't the only defining feature how a language does OOP or not.
    - randomdata 2y ago
      Go has objects, but objects alone does not imply orientation. For that, you need message passing.
    - frou_dh 2y ago
      It goes like this: 1. Software development is a fashion industry. 2. OOP is currently uncool. 3. People who identify as Go programmers don’t want it to be thought of as connected to OOP at all, because then it is uncool by association.
  - kgeist 2y ago
    I find libraries like sqlx more than enough. Instead of a full-blown ORM, they simply help hydrate Go structs from returned SQL data, reducing boilerplate. I prefer the repository pattern, where a repository is responsible for retrieving data from storage (using sqlx) using simple, clean code. Often, projects which use full-blown ORMs, tend to equate SQL table = business object (aka ActiveRecord) which leads to lots of problems. Business logic should be completely decoupled from underlying storage, which is an implementation detail. But more often than not, ORM idiosyncracies end up leaking inside business logic all over the place. As for complex joins and what not, CQRS can be an answer. For read queries, you can write complex raw SQL queries and simply hydrate the results into lightweight structs, without having to construct business objects at all (i.e. no need for object-relational mapping in the first place). Stuff like aggregated results, etc. Such structs can be ad hoc, for very specific use cases, and they are easy to maintain and are very fast (no N+1 problems, etc). With projects like sqlx, it's a matter of defining an additional struct and making a Select call.
TheDong 2y ago
> reducing boilerplate is bad Programming is about building abstractions, abstractions are a way to reduce boilerplate. Why do we need `func x(/* args / ) { / body */ }`, when you can just inline the function at each callsite and only have a single main function? Functions are simply a way to reduce boilerplate by deduplicating and naming code. If 'reducing boilerplate is bad', then functions are bad, and practically any abstraction is bad. In my opinion, "reducing boilerplate is bad in some scenarios where it leads to a worse abstraction than the boilerplate-ful code would lead to". I think you have to evaluate those things on a case-by-case basis, and some ORMs make sense for some use-cases, where they provide a coherent abstraction that reduces boilerplate... and sometimes they reduce boilerplate, but lead to a poor abstraction which requires more code to fight around it.
bobnamob 2y ago
Not liking ORM I can understand, db table <-> object impedance mismatch is real, but "reducing boilerplate is bad" is an interesting take. Can you elaborate and give some examples of why reducing boilerplate is generally "bad"?
- rad_gruchalski 2y ago
  Not the person you’re replying to. The orm sucks because as soon as you go out of the beaten path of your average select/insert/update/delete, you are inevitably going to end up writing raw sql strings. Two cases in point: postgres cte and jsonb queries, there are no facilities in gorm for those, you will be just shoving raw sql into gorm. You might as well stop pretending. There’s a difference between having something writing the sql and mapping results into structs. The latter one can be done with the stdlib sql package and doesn’t require an „orm”. There are two things an sql lib must do to be very useful: prepared statements and mapping results. That’s enough.
  - bobnamob 2y ago
    You haven’t answered my question at all. The parent comment made two claims: ORM not great (I agree) and “boilerplate reduction bad” which still needs some elaboration
    - rad_gruchalski 2y ago
      I answered it, you just don’t see it. One ends up with the boilerplate anyway as soon as one attempts to step out of the usual crud path. There’s no gain, there’s no difference in templating an sql string vs fighting an orm api.
  - metaltyphoon 2y ago
    Perhaps you have to yet use a good ORM? I could probably count on my fingers the times I had to drop to raw SQL in EFCore. Even when you do that you can still have mapped results, which reduces boilerplate.
deleted 2y ago
[deleted]

indulona 2y ago

understandable. thee are always valid uses cases. although ORM in Go is not something that is widely used.

the_gipsy 2y ago

gorm just takes a pointer of your type and does reflection magic. It's worse than generica, I agree, but you don't get []any.