I'm not sure GoogleSQL is, for all intents and purposes, anything more than just a particular SQL implementation. Notably, it still breaks from the relational model in the same way and, as such, is prone to the very same bugs of which we speak.
The closest thing to the 'Rust' of SQL is probably Datalog. Even something like QUEL, which Postgres used for the first decade of its life, would have likely left us in a much better place.
But Oracle won the database wars, so we got left with the junk that came with it – for compatibility initially, and now we can't seem to move past SQL because the typical developer somehow has come to think SQL and relational algebra/calculus are the exact same thing...
SQL isn't the purest, but I've yet to see a real-life example of some other query language that gracefully handles queries that would be difficult in SQL. Looking at these other languages with an open mind, I still don't see them making things easier. If there's something better, then there should be examples out there showing a stark contrast in usability.
The only real alternative I can think of is the map-reduce pattern (see PySpark), but it's for a different use case with some overlap. I have replaced SQL queries with map-reduce once before, and only because the application really didn't make sense to use SQL for.
> I've yet to see a real-life example of some other query language that gracefully handles queries that would be difficult in SQL.
That's exactly it. Nothing has come anywhere close to seeing the same kind of effort as SQL put into it. SQL is the best application of relational calculus (or close approximation, at least) we have – but that doesn't make it good. A concerted effort to build a better application of relational calculus would undoubtedly yield a major improvement for developers, on the order of how something like Rust has improved over C, and as I said before it is unfortunate that we as an industry are not showing interest in a better language like we do with regards to general purpose computing.
SQL gets the job done, but we can do better.
> The only real alternative I can think of is the map-reduce pattern
The alternative is to build a better language, not jump to a completely different and unrelated model. Indeed, there is a place for map-reduce for certain problems, but they are outside of where you would use the relational model.
