> But would that radically change how queries are written? Not really.
Rust didn't radically change how applications are written as compared to C, but that didn't stop us. Nor should it. Any improvement is worthwhile. It doesn't need to be radical.
But, like another commenter points out, SQL is like Javascript. Both having ecosystems so horrendously conceived that they have ensured there is no good path to replacing/augmenting them.
Rust hasn't swept the world yet and it helps prevent real bugs and security issues. A better query language may make it fractionally easier to write database queries but you have to toss out a half-century of experience. It's not worth it for marginal gains. This isn't even opinion, this is the reason it has never happened.
I think I agree that SQL is like JavaScript. If JavaScript wasn't as expressively powerful as it is, it would have been replaced a long time ago. But it's actually good enough, despite it's quirks, that there doesn't exist a language better enough to make it worth replacement. It's possible such a language might never exist. And both SQL and JavaScript continue to improve sometimes directly stealing ideas from potential competitors.
> If JavaScript wasn't as expressively powerful as it is, it would have been replaced a long time ago.
No, it wouldn't matter how terrible or in-expressive the language is - once it got rolled out to the web browser, then it would never be replaced. That is why you have WASM nowadays - you can add new stuff but never replace stuff.
I disagree. If JavaScript was objectively limited, one of the browser makers would have just added something else and if it was good enough it would spread to others. Just like other browser technologies (for example, xmlHttpRequest). In a way, that's what happens with JavaScript right now. It continues to evolve.
Browsers did support multiple programming languages with the language attribute on the script tag. This is how Microsoft added VBScript to IE.
>If JavaScript was objectively limited, one of the browser makers would have just added something else and if it was good enough it would spread to others.
So like Shockwave, or Flash, or Silverlight, or Adobe AIR, or java applets, or the entire ActiveX ecosystem or...
We literally only moved things to javascript after Google spent a billion dollars writing a hyperoptimized javascript engine that has to make a pact with the devil (pretty much every javascript based exploit of computers relies on the fact that it is leakily compiled JIT to machine code, if javascript required less optimization to be useful, the internet would be a less exploitable place) just so that you could read your email in a web browser in a slightly less ugly way.
It also required several doublings in normal person computing power to be usable, and literal armies of 20 somethings writing in a couple giant abstraction layers that had to reinvent the world to do anything useful. It is still the primary burner of average person computing power, to run a million lines of javascript to do the exact same shit we did in the 90s with a 386.
Javascript should be seen as a systemic failure. If it's supposed to be "assembly for the web" as it seems to be treated now, then it needs to be VASTLY more efficient to run.
> So like Shockwave, or Flash, or Silverlight, or Adobe AIR, or java applets, or the entire ActiveX ecosystem or...
Yeah you complain about JavaScript but listed 6 objectively worse technologies. Clearly the best option won.
Browsers are ultimately the write-once-run-everywhere platform that everyone was trying to develop for decades. The only successful implementation of that idea. This is a case of worse is better.
And I think you're actually overselling the problem -- I have plenty of vintage machines and this text box in HN has more functionality than word processors had in the 90s. Here we are safely using literally an infinite number of apps that never have to be installed. It's an amazing achievement.
The word you are looking for is subjectively. Objective measures need to be specific.
> Clearly the best option won.
Although, if Konquerer had implemented its own Flash renderer back in the day, there is a decent chance that Flash would have won in the end. Flash failed only because there was, for all intents and purposes, only a single implementation and a notable individual didn't want to have to rely on it, breaking unanimous support.
> The only successful implementation of that idea.
SQL is the only successful implementation of that idea.
The browser has fallen quite short of any kind of success in that regard. For example, studies that have looked at iPhone users suggest that 80-90% of their "internet time" is spent in apps rather than the browser.
> The word you are looking for is subjectively. Objective measures need to be specific.
If you're going to be pedantic, you should at least try and be correct. Objective just means based on facts where subjective is based on opinions or feelings. Just because I didn't enumerate all the ways in which those technologies are objectively terrible, doesn't mean they are not.
> Although, if Konquerer had implemented its own Flash renderer back in the day, there is a decent chance that Flash would have won in the end.
But even if that was the case, we'd still be using JavaScript.
> Flash failed only because there was, for all intents and purposes, only a single implementation
...and that implementation was terrible. Full of security flaws, bugs, and insufficient investment from Adobe. But a single closed-source implementation is also a perfectly good reason why it objectively terrible as well.
> The browser has fallen quite short of any kind of success in that regard.
If Apple was not specifically crippling browser potential on their platforms, it might be more. But either way, the actual success of the iPhone was entirely based on the browser (the first version didn't even have apps). The web is what makes any alternative operating system viable today -- whether that OS is iOS, Mac OS, Android, WebOS, ChromeOS, Linux, etc.
> Objective just means based on facts where subjective is based on opinions or feelings.
Indeed, and the assertion made was based on opinion or feeling. There is no objectivity in the assertion.
> But a single closed-source implementation is also a perfectly good reason why it objectively terrible as well.
While I must share in your opinion, this again is not measured objectively. You just got finished defining the word... It is quite likely that at least someone at Adobe enjoyed it being a single closed-source implementation for a long, long time. "Terrible" is always an opinion.
> the first version didn't even have apps
Incorrect. While it did not support third-party apps (officially, at least; it didn't take long to see them added unofficially), the device was chock full of apps written by Apple.
As an aside, I always figured that the "WASM" of databases would come some day. With SQLite recently publishing details about its bytecode engine, perhaps that is looking more realistic?
> Rust hasn't swept the world yet and it helps prevent real bugs and security issues.
As the inventor of the relational model has written about extensively, and as you have no doubt came to realize yourself if you've used SQL for more than a few minutes, a different query language could have prevented a whole lot of real bugs too. SQL also has its fair share of security problems that are only prevented by telling developers to be careful.
Rust will never sweep the world, of course, because there is no reason to choose a single language in the application space. Something sweeping the world tells that you royally screwed up the execution environment. But it is a viable contender, despite being no different than C in any meaningful way (clearly you don't see bug/security issue prevention as being meaningful).
> despite it's quirks, that there doesn't exist a language better enough to make it worth replacement.
As you know, Postgres went in the opposite direction, eventually switching to SQL. A DMBS – one which is probably the second most popular DMBS in existence at that – completely upending what query language it supports is not without precedent. What do you think it was about SQL that made it substantially better to justify the change?
You seem to have my point backwards. It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL. Ultimately, what made Postgres interesting wasn't the query language.
> a different query language could have prevented a whole lot of real bugs too. SQL also has its fair share of security problems that are only prevented by telling developers to be careful.
I can't think of an example where one of these newer query languages actually solve bugs in the way that Rust does with the borrow checker. Slightly better syntax may prevent bugs but no where near in the same way. I don't find SQL particularly bug-inducing -- it's mostly just annoying.
> It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL.
You seem to have your own point backwards, unless you have failed to make one. The premise you gave, at least as I understand it, is that there is no reason to put in the effort in moving away from SQL because nothing else is substantially better. So, by the same token, unless SQL was substantially better than QUEL, there should have been no reason for Postgres to put in the effort to make the same transition.
Which implies that SQL was substantially better. The question was: In what way?
> I can't think of an example where one of these newer query languages actually solve bugs
Perhaps because you are getting hung up on newer? They need not even be newer. The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha.
[1] Problem might not be the right framing, but I lack a better word. There is no problem if you write perfect queries every single time. But, like C, it opens opportunities for making mistakes that could have been made impossible with a different design.
> Which implies that SQL was substantially better.
That is begging the question. It doesn't have to be selected because it's substantially better. If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option.
> The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha.
> If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option.
There is a good case to be made that, for better or worse, single page applications (SPAs) are the more popular/standard option as compared to generated HTML, even if roughly equivalent, for web applications. Does this mean that HN is making a mistake in not adopting that model? You did say always.
It is not like Postgres was a new project and they simply had to pick something. It had been with us for a decade before deciding to take the SQL direction. It could have much more easily continued down the path it was already going. There was a significant amount of cost involved to make the switch.
When Postgres was first created there was no clear winner, but by the time the switch was made it was apparent that SQL was becoming the more popular choice, I'll give you that. Is that the only reason for the move?
Thing is, I'm not sure SQL is even all that popular nowadays. I expect the vast majority of DBMS queries are only using SQL as a compiler target, more likely being written in a class of languages often referred to as ORMs. By your logic, databases should be adopting what best aligns with that programming model rather than clinging to SQL. You did say always, after all.
Granted, there are some half-hearted attempts to do exactly that by some DBMS vendors (e.g. recent Oracle releases support "3D" queries that return JSON structures rather than relations, more closely matching language semantics), but not in any way that appears to be all that serious and definitely not in any kind of consorted way. It seems the SQL crowd still can't get over that there might be an alternative. In fact, often they can't even envision anything other than SQL being possible. I don't know how many times I've heard someone claim that SQL is some kind of fundamental mathematical property.
> What was that?
The most common SQL bug I see in my travels can be distilled down to something like:
SELECT t1.* FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id
To be fair, I'm not sure the bug would go unnoticed with such a simple query - where one is able to keep the entire mental model in their head. But consider the basis of that query expanded into something complex, where one will struggle to maintain all of the minute details in active memory. That is where I see bugs be introduced all the time, even by experienced developers. A different design – including the originally designed database query language – has proven to eliminate this class of bug.
There is not. Counterpoint: Wikipedia. It's definitely not like this where SQL is used by 99.99999% of everyone and nobody has even heard of QUEL.
> It is not like Postgres was a new project and they simply had to pick something. It had been with us for a decade before deciding to take the SQL direction.
It wasn't even remotely popular until they made that change. In fact, it wasn't even remotely popular until years after they made that change.
Probably the interesting point is that they could make this change and not really lose any necessary functionality. Clearly the query language was not particularly important.
> Thing is, I'm not sure SQL is even all that popular nowadays.
A suggestion so laughable I have no response. SQL has never been as popular as it is right now in history. Even with the introduction of noSQL databases, SQL continues to gain. All boats are floating.
> By your logic, databases should be adopting what best aligns with that programming model rather than clinging to SQL.
Is there something they can adopt? If you presented me with 2 options, lets call one X and other SQL then we could have discussion about adopting one or the other. If this X was indeed more popular then maybe they shouldn't cling to SQL. But the dozens of ORMs across dozens of platforms is not an alternative that can be chosen.
> It seems the SQL crowd still can't get over that there might be an alternative.
If you've been around long enough you wait until someone can bring the receipts.
> The most common SQL bug I see in my travels can be distilled down to something like:
Yeah that is pretty common. Would it be nice if that wasn't an issue? Sure. I'm not arguing that an alternative might not be better, it's just not better enough. These are pretty minor annoyances. If you just made a language that fixes this one issue and left everything else alone, it would be better than SQL, but you wouldn't get anyone to switch. You'd be better off proposing this as a feature addition to SQL and maybe in 20 years you'll be able to use it.
> SQL has never been as popular as it is right now in history.
As a compiler target, but even then the SQL is compiled to another representation, so if you want to take that angle it isn't SQL that is popular. Turtles all the way down.
> Is there something they can adopt?
What Oracle is doing was already mentioned. I am personally not entirely sold on their technical choices, and feel that they are trying to stay too close to SQL unnecessarily, but at least they are trying something which is more than we can say for a lot of the other vendors out there. I commend them on that.
> If this X was indeed more popular
It isn't what I would call popular, but it is also rather new. It is quite unusual for a technology to become immediately popular. Though, frankly, I'm not sure it could become popular if never adopted by any other engine. Oracle doesn't have a stranglehold on databases, and if anything is losing ground. Popularity can never come before wide distribution.
> If you've been around long enough you wait until someone can bring the receipts.
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. 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.
> You'd be better off proposing this as a feature addition to SQL
It is...? I believe it has been since the very beginning, or at least since the early days. It's such a glaring issue, of course it had to be dealt with. But you have to remember to enable it – which most of the time it seems developers forget, at least in my travels.
Of course, by the same token, if you are able to remember such things, what do you need Rust for? You can avoid bugs and security issues in C just fine if you keep a clear head and never make mistakes. So, Rust doesn't do anything meaningfully different from C, except in the places you suggest don't matter because as long as you don't make mistakes you'll never need it, and yet despite that has gained a decent following. Why it but not some SQL alternative?
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.
> 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.
Rust didn't radically change how applications are written as compared to C, but that didn't stop us. Nor should it. Any improvement is worthwhile. It doesn't need to be radical.
But, like another commenter points out, SQL is like Javascript. Both having ecosystems so horrendously conceived that they have ensured there is no good path to replacing/augmenting them.