> Truly efficient distributed systems are most naturally expressed through functions as triggers invoked from upsert operations on addressable relations
O_o
Just because you can express something as an 'upsert', that doesn't make it 'relational'. Transactions exist outside the concept of rdbms'. The article doesn't mention relational algebras once.
Yes, a lot of terminology and math in rdbms' are useful in distributed computing, but you have the causality backwards.
I don't get all the author's hate for sql. It's one of the most successful declarative languages ever.
Nothing prevents you from modelling a distributed system as a set of key-value stores (as we often do today), the idea of a message queue is independent of using a database
as the mechanism to do so. 'using postgress'/rdbms doesn't mean your entire system is 'relational'.
Wouldn't it be better for D to lazily request information from b and c on your behalf in the 'maximally efficient' case? Given D is where the computation is run and it could cache the results. From an auth perspective that seems simpler than cross wiring connections between all nodes as proposed.
All this talk and nothing about n-phase commits or Byzantine generals/any tie backs to the typical way of talking about distributed computing, but they dance around the subjects.
IDK. Sorry man. Didn't like the article, which feels bad because you seem passionate about the presentation of it.
Edit: looked through the sub stacks other posts. They do kinda talk about relational algebra in a subsequent post, but overall I'm curious if the author has looked into dataflow programming before. It seems like the author is kind of trying to describe that concept but with a vocabulary mostly consisting of rdbms terminology and history
I feel like the author needs to read the Out Of the Tarpit paper if they haven't already. It feels like they are grasping at some of the concepts that are presented there in a far clearer fashion.
> I don't get all the author's hate for sql. It's one of the most successful declarative languages ever.
To be fair, they criticize SQL as a language for writing triggers, which are imperative by nature, and SQL/PLSQL as an imperative programming language does suck.
O_o
Just because you can express something as an 'upsert', that doesn't make it 'relational'. Transactions exist outside the concept of rdbms'. The article doesn't mention relational algebras once.
Yes, a lot of terminology and math in rdbms' are useful in distributed computing, but you have the causality backwards.
I don't get all the author's hate for sql. It's one of the most successful declarative languages ever.
Nothing prevents you from modelling a distributed system as a set of key-value stores (as we often do today), the idea of a message queue is independent of using a database as the mechanism to do so. 'using postgress'/rdbms doesn't mean your entire system is 'relational'.
Wouldn't it be better for D to lazily request information from b and c on your behalf in the 'maximally efficient' case? Given D is where the computation is run and it could cache the results. From an auth perspective that seems simpler than cross wiring connections between all nodes as proposed.
All this talk and nothing about n-phase commits or Byzantine generals/any tie backs to the typical way of talking about distributed computing, but they dance around the subjects.
IDK. Sorry man. Didn't like the article, which feels bad because you seem passionate about the presentation of it.
Edit: looked through the sub stacks other posts. They do kinda talk about relational algebra in a subsequent post, but overall I'm curious if the author has looked into dataflow programming before. It seems like the author is kind of trying to describe that concept but with a vocabulary mostly consisting of rdbms terminology and history
https://en.m.wikipedia.org/wiki/Dataflow_programming