| > Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? I think... we're in a agreement? :) EdgeQL doesn't have a NULL (it's a set-based language and NULL is an empty set, this tiny adjustment makes it easier to reason about missing data). And because it also has a more robust type system, allows for limitless composition and easy refactoring, it has far greater DX than SQL => you're more productive. There's a footnote here: EdgeQL doesn't support some of the SQL capabilities just yet, namely window functions and recursive CTEs. But aside from that it is absolutely a beast. > Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me. Maybe, but I'm curious how you arrived to that conclusion. I assume you mean that using the power of a high-level programming language you can force ORM to complete submission and that's just not true. Most of the time you'll either have grossly inefficient multi-roundtrip query code (hidden from you) or let ORM go and use SQL. Obviously that's an extreme scenario, but it's surprisingly common in complex code bases and logic. > Aha, so then... why not build a query builder for every language, just like with ORMs? We are. We started with improving the network protocol (it does less round-trips than Postgreses and is stateless) and crafting client libraries for MANY languages. All client libraries support automatic network & transaction error recovery, automatic connection pooling, and have generally great and polished API. Not to mention they are fast. We do have a query builder for TypeScript. But we also have codegen for every language we support: place an .edgeql file in your project and you get fully typed code out of that. That said, we will eventually have query builders for every language we support. There's only so much you can do in 3 years since we announced 1.0. > Sorry, not convinced. We would be better off by improving on SQL itself. Significantly improving SQL without starting from scratch isn't possible. Adding sugar - surely is possible, but we are 100% that the productivity boost we deliver with EdgeQL is worth going all in (and our users agree with us). In any case, with Gel 6 we have full SQL support (except DDL), so it's possible to use Gel along with ORMs if that's needed. We are not SQL haters at all. We have this blog post that was on HN front page a few times, it's a good read and explains our position: https://www.geldata.com/blog/we-can-do-better-than-sql |
Or you spend 5 minutes actually putting some effort in to configuring your ORM. Maybe spend 30 minutes learning if it's your first time. People will spend weeks handwriting SQL to save hours of ORM tuning.