Every time I see these layers on top of SQL I think: Just use regular, boring SQL

It will be around for a long time, there's an infinite number of resources and examples for it and if you ever have to onboard someone into your code they don't need to learn something new. You can get pretty far by just using CTEs to "pipeline".

"Pipelined" SQL already exists in the form of common table expressions. I don't know of any providers where this is not available. SQLite has had support since 2014.

Kusto is similar: https://learn.microsoft.com/en-us/kusto/query/

Google's "pipe syntax" is a similar idea: [0]

It's not as elegant as PRQL, because of course it's bolted onto the existing SQL syntax, rather than a redesign from scratch. But it has a big name behind it, and it's actually running in prod in Google Cloud... so it might have more momentum.

[0]: https://cloud.google.com/blog/products/data-analytics/simpli...

Procedural language fanatics have been trying for years to overturn the best declarative language for relational data.

PRQL is declarative. They are just heeding the maxim "If it's broke, fix it".

Is this project stalling out? The last post on the "posts" page is from March 2023. But the last commit to the git repo was last week...

Matching SQL in features is very hard, especially if you also want to make it more sane and more powerful at the same time while also wanting to be able the generate valid SQL from your syntax. So I am not surprised that it stalled out.

Sure, but they never intended to support everything you can do in SQL. For example, they say on the Roadmap page that they're only going to support SELECTs -- there won't be a PRQL way to do an INSERT, UPDATE, etc.

The title of the submission is literally the first line on the website.

I always find that funny. If you have to provide a pronunciation guide for your product, perhaps consider a different name. I guarantee you’ll still have people pronouncing each individual letter, either because they don’t know or because it’ll be less ambiguous.

> I wrote SQLite, and I think it should be pronounced "S-Q-L-ite". Like a mineral. But I'm cool with y'all pronouncing it any way you want. :-)

For the first half of the 90's I pronounced Linux as "LINE-nucks". Then while he still had a thick accent, Linus told us all how he pronounced it "LEE-nooks".

I mean, as someone who grew up pronouncing it "Ess-Cue-Ell", I wish I learned earlier on that "Sequel" was the intended pronunciation. :)

Yes, in Ukrainian/Russian PRQL can be easily read as "prikol" (joke/gag/quirk). But I guess the best name would be "perkele" (emotional, like "damn") in Finnish.

I continue to pronounce it S-Q-L... and G-U-I; generally I pronounce most things as initialism and I'm right to do so.

I always used ess-cue-ell to refer to the language, and sequel to refer to the Microsoft product. It would never occur to me to pronounce the Open Source alternative as postgressequel either, that's also invariably called post-gress-cue-ell here.

Which is my point. A better name wouldn’t have had that problem. How could you ever know how it’s pronounced if you bump into it on a blog or social media post instead of the official website? We don’t write “SQL (pronounced “sequel”)” every time, we just write “SQL”.

But even then, it makes sense to choose to pronounce it “the wrong way”. I say “sequelite” because that’s fairly clear in context, but “sequel” might not be so I pronounce each letter in that case.

Did know PNG is supposed to be pronounced “ping”? I don’t know anyone who chooses to do that, even if they know.

I pronounce PNG "ping". Also JPEG as "jay peg" but, counter to the creator's intention, GIF with a hard "g".

Nobody calls it sequel in my country.

Even people who know because then they have to explain it which wastes time for no benefit.