Casey is right, but the whole point for the Rivian position is they see themselves as the car software platform of the future. The idea we want primarily phone UIs in our cars is antithetical to their very existence, or why VW invested in them.
The idea customers should have control over the interfaces they use needs to be reinforced. If anything this is why the AI wave has gained so much hype as now people get to bypass so much nonsense masquerading as UX.
Because it converts all normal DBA tasks into development tasks. If this fits your org (and at huge scale it is more likely) then that's fine, but for small/mid/growth places that can be a PITA.
There does seem to be more effort going into an SQL layer, but it's very hard to know what the state of layer dev and direction is these days, especially if you're not located near core devs.
This has been de facto true for a while, not that it improves the situation. Various EU countries have legal limits for the size of cash transactions, requiring you to do it via a bank.
The idea that people have private property does seem to be something governments are incredibly keen to erode.
One dimension of this which isn't discussed enough is this opens the road to inference providers silently discriminating against different users who will remain oblivious to what's going on. i.e. if you "fail" ID verification it's actually good that they tell you as opposed to serving you a malicious model instead.
> And the obvious rebuttal to that is that it's equally hard to provide an upper bound for the runtime of a single insert
This is precisely where you're going wrong. The insert is upper boundable in advance (you know the set of everything you might potentially have to insert), the delete isn't because you don't know what's in the db until you look.
I strongly recommend poking around with Foundation for this, because it becomes clear that this problem is the defining flaw with the way they tried to architect with layers, to the point they have a queuing system for processing large jobs of this type.
The whole problem with the delete cascade is you can't tell how big it will be until you have entered the transaction to do it. An insert you either know or it will fail and you can retry.
> I'm not aware of instances where a delete is "far more work" than an equivalent insert though. That's not the general case, and I'm having a hard time thinking of any situations where that would be true.
Transactionally across related items with constraints it can explode fast.
If you've ever used FoundationDB this rapidly becomes the defining PITA due to the transaction size limits. Adding/inserting/updates are all far more predictably bounded.
The gov do all this and then will act surprised as Canada's tech sector finds it even harder to create any consumer facing businesses leaving all the value being captured by the Americans. Surprised pikachus all round.
The enormous question here is if AI works the way these people say then surely competing companies will emerge that are enormously smaller and more agile, thus eating their lunch completely.
The fact this doesn't appear to be happening suggests something different is in play.
The idea customers should have control over the interfaces they use needs to be reinforced. If anything this is why the AI wave has gained so much hype as now people get to bypass so much nonsense masquerading as UX.