I'm pretty excited about PRQL. If anything has a shot at replacing SQL, it's something like this (taken from their FAQ):

PRQL is open. It’s not designed for a specific database. PRQL will always be fully open-source. There will never be a commercial product.

There's a long road ahead of it to get serious about replacing SQL. Many places won't touch it until there's an ANSI standard and all that. But something built with those goals in mind actually might just do it.

I'm not too much of a fan of the SQL equivalent of SELECT not being at the top. Granted I'm fairly sure there are some arguments for it. Since select is optional there's a higher mental load trying to figure out where and what is actually being returned imo. At least from looking at this for the first time.

On the other hand, i'd kill for f-strings, the top N in group (which is nigh unreadable in SQL), and null handling that doesn't require me to write either COALSECE or NVL too often. The joins were a little less pretty though, I'm quite fond of normal SQL joins since they are very reasonable unless chained beyond the line count your screen can show.

You can write selects with many joins, as long they are regular and either add a column or reduce the result set. You have to write the joins explicitly though. Just shoving all of the restrictions into the where clause will definitely confuse everybody.

The main advantage being more concise syntax?