| > As a compiler target Not as a compiler target. I doubt most projects exclusively use ORMs and never use SQL as a query language as intended. Also it's not just programmers using SQL inside of programs -- I teach SQL to accountants and they run their own queries. Any SQL alternative needs to be something accountants can learn. I use an ORM all the time but I wouldn't use an ORM for reporting queries. Absolutely nobody abstracts over SQL for general purpose querying. > But now we circle back to the original posts – there is no good vector for anything else to bring said receipts. SQL has things completely locked down, effectively, which you suggest can only be overcome by becoming more popular than SQL, but, again, popularly is impossible before wide distribution. You've got it. > So the only possible way off of SQL is to convince the SQL crowd that an alternative is possible in hopes that they will consider opening things up. That's not how things work. You build something amazing and find a way to make it useful today. This is nothing new, it has been done through the history of technologies. This is how we get new programming languages, new protocols, and new standards. You could have said the same thing about x86 but ARM found a niche and expanded it. Or JSON vs. XML. > It is...? Is it? I don't know what you mean. > Why it but not some SQL alternative? I never said it couldn't be done -- it just hasn't been done. Any alternative to SQL has to have all the positive features of SQL and be a significant and obvious improvement. The majority of alternatives I've seen are intent on being radical redesigns. Rust, as you said, is not really radically different from C++ -- they just removed most of the footguns and design problems. Any alternative to SQL needs to find a way to be immediately useful today. This is how NoSQL solutions became popular; the solved a real problem and I could use it today within an existing environment. But NoSQL is not a replacement for SQL -- it was just a replacement for tasks that an RDBMS was never good at in the first place. But I think the idea of someone just building a better query language in their basement, posts it to Github, and we should all just move over is pretty unrealistic. I could build one of those tomorrow if I wanted. |
If projects use 90% ORMs and 10% SQL, ORMs are still widely more popular. This exclusively you are trying to draw is nonsensical.
> Any SQL alternative needs to be something accountants can learn.
Try reading the thread next time. The entire discussion is about how SQL's biggest screw up is the lock-in. The better solution would clearly allow SQL to coexist. If accountants want to use SQL, there should be nothing holding them back. You can still write code in C too, if you want to. The existence of Rust didn't put an end to it, nor should it.
> Is it?
It is. You commonly see the problem as said earlier, but never deal with it, just leaving the bug there?
> This is how NoSQL solutions became popular; the solved a real problem
Indeed, they offered an alternative API which solved the real problem that is known as SQL – hence why the movement became known as NoSQL (i.e. literally "no SQL"). Unfortunately, most of the implementations that offered better APIs fell short in the actual database-y bits, souring the effort, which has ultimately also quashed any progress in improving the APIs over databases you can use.
> Any alternative to SQL has to have all the positive features of SQL and be a significant and obvious improvement.
Therein lies the problem here. Rust brings no significant and obvious improvement over C. It might be marginally easier to use, and might prevent a bug here or there, but in the end it doesn't do anything radically different from C. The same can be said of most SQL alternatives. Yet Rust "made it" regardless where the others haven't.
Of course, Rust had the power of marketing behind it. Being a Mozilla project originally, it had a built-in audience, and the flashy video they released extolling its virtues back in the early days won sufficient hearts and minds. Other than maybe Oracle who at least seems to be giving some minor effort, the big names are stuck on SQL.
Although credit to SQLite for recently documenting its bytecode format. While they have not committed to it being a stable API, and probably isn't suitable as an API in its current form, it does provide a framework in which to start considering a "WASM" for database engines. This will undoubtedly happen someday if we keep the pressure on the SQL crowd to change their ways. And, indeed, they are evolving. The "SQL is a fundamental mathematical property" claims have diminished greatly over time, and they are even starting to recognize that there have been alternatives, like QUEL. It's a slow road, but one that continues.
> I could build one of those tomorrow if I wanted.
And I'm sure it would be the greatest thing the world has ever known, but since nobody knows who you are, there is a fat chance of anyone ever coming to realize that it exits. It is not sufficient to just be significantly better.