4 ms·
Sorry, but this post just shows a lack of experience in dealing with distributed systems. Joel was bang on the money about the problems of disguising network in
by lll-o-lll 4y ago
Sorry, but this post just shows a lack of experience in dealing with distributed systems. Joel was bang on the money about the problems of disguising network interactions in applications.
Async vs Sync is not enough. Network partitions have multiple failure modes depending on a range of factors, but one of the most pernicious is the “undetectable cloud break”, an invisible break between two routers. Having a well defined “api” that is the clear “we are communicating over the network here” makes it much easier to reason about and handle these issues.
There is an enormous difference between “this I/O call failed” and “this I/O call took 10 minutes to fail”.
- IshKebab 4y agoI don't see why automatically converting functions to RPC APIs is incompatible with a clear "we are communicating over the network". Just put all the RPC functions in their own `network` namespace or whatever.
- Yoric 4y agoOne counterpoint to that is that this works very well in Erlang (and Elixir) and has done so for 30+ year. Well, I might be cheating a little bit with my definition of "so" :) I'll agree with you that it's not a trivial change, far from it. You need switching your mindset from local to remote, from procedures to agent messages, from exceptions to non-local error-handling, but it remains quite simple and readable. I feel that Telefunc is bringing developers a good chunk of the way towards that goal. And, who know, maybe there is another simple model that is not exactly agents, and that would also work nicely.
- kentonv 4y agovlovich123 built Cloudflare's R2, I think he has some experience with distributed systems. The RPC debate is confused because the two sides of the debate have different ideas of what RPC is. The anti-RPC crowd is arguing about RPC systems from the 80's, which tried to make RPC look exactly like a local function call, including blocking until the call was complete. The pro-RPC crowd is mostly speaking from experience using modern RPC systems which do not do this; they use asynchronous callback APIs, have some mechanism for reporting network errors, etc. Modern RPC systems are called RPC because they encourage you to organize your network API conceptually into something like function calls, but they certainly do try to hide the fact that there is a network here that can fail in all the ways networks fail.