The author should check out Quill[1] as prior art. Compile-time query generation where you can see the generated query just by hovering over the code is chef's

The author should check out Quill[1] as prior art. Compile-time query generation where you can see the generated query just by hovering over the code is chef's kiss. One of the terrible things about most ORMs is that you can't see the queries when you look at the code. There's usually some awkward hoop you have to jump through to see it, like writing a unit test and logging the query from it, and Quill bypasses all of that. [1] https://getquill.io/ https://getquill.io/ Overall I'd say that this post does a better job of presenting the trade-offs than most. Some of the statements ring false to me, but I won't bother picking nits. > Portable Across Languages This is interesting, because what you're proposing in this section is a better SQL. I don't think that's a bad idea. A relational DDL and query language that is optimized for integrating with modern programming languages might be enough of a step forward to actually displace SQL. However, implementing it as a middle layer between SQL and a programming language doesn't seem like the way to go, because it adds an extra layer that programmers have to understand. Make no mistake, people will encounter problems even if the tooling is perfect, because their own understanding won't be perfect, and they will have to go on debugging odysseys to fix their understanding, by tracing down through the layers from their code to SQL. Now you're adding a language that is just as powerful as SQL, maybe more powerful, right in the middle. I would never in a million years use a tool architected like that. The potential for getting bogged down in the details of how the different layers translate is too high. This is why after all these years of ORMS and other database libraries people often still embed SQL in strings in their code. It isn't (always) because they're stupid or stubborn. It's because they know that embedding literal SQL puts a hard ceiling on an entire dimension of debugging. Painfully often, when I ask somebody, "I think there's an error in this code that queries the database. What SQL does it generate?" they reply, "Oh, give me a second, I have a Datadog trace that shows it, I just have to find that link," or, "Let me run this unit test that logs it." Or, even more depressingly, they haven't even seen the SQL yet, because there were other things that were easier to investigate, so they investigated the easy things first even though they suspected the query was the culprit, like the proverbial drunk looking for his keys under the streetlight instead of where he thought he dropped them. Introducing another equally powerful conceptual layer between code and SQL is a step in the wrong direction. Replacing SQL with a better query language that integrates better with code would be great. It will happen someday; fingers crossed it will happen in our lifetime.