> Truly efficient distributed systems are most naturally expressed through functions as triggers invoked from upsert operations on addressable relations<p>O_o<p>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.<p>Yes, a lot of terminology and math in rdbms' are useful in distributed computing, but you have the causality backwards.<p>I don't get all the author's hate for sql. It's one of the most successful declarative languages ever.<p>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'.<p>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.<p>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.<p>IDK. Sorry man. Didn't like the article, which feels bad because you seem passionate about the presentation of it.<p><i>Edit</i>: 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<p><a href="https://en.m.wikipedia.org/wiki/Dataflow_programming" rel="nofollow">https://en.m.wikipedia.org/wiki/Dataflow_programming</a>
In the first diagram I see well-encapsulated services B, C and D and their orchestrator A.<p>In the second diagram I see ill-defined responsibilities and a looming callback hell.<p>What if we could look at more concrete examples with a dozen services that model a real process? Maybe that would elucidate the benefits.
> A distributed computing system, then, is naturally expressed as a set of relational stores with triggers.<p>1. This statement is too big of a leap; it doesn’t follow from the setup which only required an upsert operation and key/value storage. Nothing in the setup example requires relational algebra. Agree?<p>2. This seems like a hasty generalization. Is the author claiming that the toy example is representative of distributed systems? If so, what aspects?<p>IMO, the post started strong but fizzled; this is why I’m giving pointed feedback.
The request/response optimization discussed in the first half of this post has been explored quite a bit in the context of Object-Oriented Programming and Actors, where the desired feature is called "Promise Pipelining":<p><a href="http://www.erights.org/elib/distrib/pipeline.html" rel="nofollow">http://www.erights.org/elib/distrib/pipeline.html</a><p>Outside of the E programming language and in the realm of language-agnostic tooling, you can find promise pipelining in some RPC frameworks, such as Cap'n Proto:<p><a href="https://capnproto.org/rpc.html" rel="nofollow">https://capnproto.org/rpc.html</a><p>Generally, this work comes from the Object-Capabilities community.
This article claims that the sequential messages of the first examples can be replaced by database operations for performance.<p>I would like to see someone run the experiment. Databases come with their own overheads, after all.