> Not as a compiler target. I doubt most projects exclusively use ORMs and never use SQL as a query language as intended.
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.
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.