Constraints in Go

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.

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

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.

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

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.

Go has objects, but objects alone does not imply orientation. For that, you need message passing.

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.