I think you have it the wrong way around. ORMs, and I’m including Ecto here, mainly exist to make up for two big shortcomings of SQL: that it does not compose well, and that it does not perform structural transformations well. I’ll focus on the first one.
SQL does not compose well because it’s a bad language. Other languages, like QUEL that came before it, were much more elegant. SQL was designed carelessly but was backed by IBM so it won by default. Similar to JS, though I would say SQL is worse.
This is why ORMs exist: to fix a problem (composition) which should have been handled by SQL itself. Unfortunately most ORMs also contribute some nasty warts of their own, specifically the disaster that is “object-oriented programming” and the addition of globally mutable “row” objects that can be modified as side-effects and then inadvertently committed. Ecto is amazing because it’s an “ORM” that does not have this problem. Because Elixir does not have this problem.
This project, the SQL library, does have composition. That’s why I personally love the name: I think it’s hilariously ironic because if you add composition to SQL it is clearly no longer SQL. You have invented something else that looks like SQL but isn’t because it actually composes properly (unlike SQL).
The fact that it sounds exactly like the design philosophy of Ecto is the whole point. I like Ecto, so I like this!
I’m sure @Schultzer could give you a list of his perceived advantages, but personally I don’t really care. I don’t think projects need “advantages” to justify their existence. It’s okay to just make something because you feel like it. In fact, if you look closely, you will find that this is where most good things come from.
