Remote procedure calls (or whatever it is called) simply can never really feel like local functions. It has been tried again and again for decades.<p>Maybe call it "removes as much friction as possible compared to local functions" but please don't call it "feels [exactly] like local functions". It's simply impossible and pretending so will just cause trouble.
"Predictive Retries: With the help of AI Differential detects transient errors (database deadlocks) and retries the operation before the client even notices. See Predictive Retries for more." [<a href="https://docs.differential.dev/" rel="nofollow">https://docs.differential.dev/</a>]<p>"If it's predicted to be transient, Differential will retry the operation on a healthy worker before the client even notices." [<a href="https://docs.differential.dev/advanced/predictive-retries/" rel="nofollow">https://docs.differential.dev/advanced/predictive-retries/</a>]<p>I… er… wat? Does that mean this behavior is nondeterministic, driven by what some extra component cooks¹ up on a per-call basis?<p>…<p>Doing this without developer input is such a horribly bad idea, and then debug it when something (not even in the RPC layer) goes wrong?<p>[Edit:] "You can turn this feature on for your cluster using the Console. It's off by default." – a breath of relief.<p>--<p>¹ I really had to resist the temptation to say "hallucinates" there.
Usually type safety isn't the issue, rather pretending the network doesn't exist.<p>RPC, even if running on the same machine, is distributed systems land.
This might be an interesting project. "Type safe RPC" is not a great description to lead with as remote procedure calls have a large amount of negative associations that have little to nothing to do with static type systems.<p>I <i>think</i> it's a distributed language runtime where you write functions in typescript and the runtime deals with passing data between machines.<p>The website is quite good at presenting the system as a nice thing that does nice things and you should like it and it's all very nice. It does a very poor job of convincing me that it works properly. I'd want to know how the scheduler works and how it handles mutable state in the presence of network partitions.<p>Also just found a caveat which amounts to they've got the implementation wrong:<p>> Arguments must be JSON serializable. This means that you can pass strings, numbers, booleans, arrays, objects, and null. You cannot pass functions, promises, or other non-serializable objects
The site lists all those features but it's not clear what problem it's trying to solve. Only in the FAQ at the end of the page it's said it's a service mesh basically with added bells & whistles, from what I understand.<p>But I'm still confused:<p>>Monolithic codebases don't have to result in monolithic services.<p>Why would I want to replace straighforward function calls with network calls in my monolith?<p>>By using a centralised control-plane, Differential transparently handles network faults and machine restarts with retries, all without changing your existing programming paradigm. It is designed to be a drop-in replacement for any function call that you'd like to make distributed and reliable.<p>"Centralization" and "reliability" don't sound like words that often come together. What if the control plane goes down? Unless they have a cluster? It's all self-imposed problems anyway: if we don't have network calls in the monolith, we don't have all those problems in the first place (which need to be solved with retries etc.)
How does the idempotency work? I don't understand how functions can be made idempotent without changing or instrumenting their implementation for end-to-end idempotency.
Is this just like trpc? <a href="https://trpc.io/" rel="nofollow">https://trpc.io/</a><p>Or like rspc (in Rust) <a href="https://www.rspc.dev/" rel="nofollow">https://www.rspc.dev/</a>
The downside of an approach like this is that it limits you to a single programming language on both the frontend and backend. This is exactly the reason RPC frameworks like gRPC use an IDL.
I'm curious if people's qualms around abstracting the cloud/network also apply to the <a href="https://modal.com" rel="nofollow">https://modal.com</a> product. Differential seems like a similar project at its core, just focused on the Typescript + microservices ecosystem.
It's an interesting/useful concept and most big tech co's I've worked at have some form of this internally.<p>But I think it's a little dangerous to market this as "feels like local functions". It glosses over a lot of really important technical considerations (like, the network and all the dragons that come with it) which will eventually bite people who <i>don't</i> understand that, and will immediately turn people off who <i>do</i> understand that.<p>I'm not a marketing or copy expert by any means, but what might be a neat product is (rightfully) getting criticized in the comments here for the positioning.
How would this work in a serverless scenario where handler side runs in a Lambda for example?<p>It seems a bit of a chicken and egg in this case.<p>A service needs to register itself with a control plane. But for the service to start it needs to get a request (via lambda invocation).
One of the authors here.<p>Ok, this blew up, and I appreciate the engagement. We will attempt to get to all the questions.<p>We are still polishing the initial offering, so if the documentation seems lacking, it's because it very much is so. Honestly, we did not anticipate having this many eyes on the project this early.
Is it suitable to use in the browser-server architecture? I think the documentation lacks scenarios or use cases, which should also be included on the home page.