There have been several languages claiming to fix SQL and none of them (to my knowledge, I'd love counter examples) have achieved widespread enough adoption to be named a proper successor.
Reasons I can guess:
- SQL's 50 years of entrenchment- all RDBMSs speak it! Most monitoring systems speak it! Any successor language needs a good interop story so people can use it with their existing systems.
- SQL is good enough for run of the mill day to day tasks- and these days by the time I'm lost in recursive queries or window functions, I can ask an LLM for help. Maybe a successor language can win on IDE support or other parts of the dev/agent experience
Successor languages also tend to only replace parts of SQL (usually the queries, not the insert/update stuff). I think PRQL does this (once again I'd love to be wrong). Now the dev has to learn two languages?
I guess my point is that a successor language, can't just fix the semantic issues with SQL, to be successful it also has to provide large ecosystem (and maybe political) steps up. I didn't see any of that in this abstract, which kills my excitement.