4 ms·

Issue with RPC was that network calls were masked like they were ordinary calls. But they're not ordinary calls, they might take a long time to respond, they mi

Issue with RPC was that network calls were masked like they were ordinary calls. But they're not ordinary calls, they might take a long time to respond, they might fail because of network issues, you could send request and then fail to receive response. Those kinds of situations are not common with ordinary calls, so it creates some kind of impedance mismatch. For example it's not possible to call JS function, it'll work and they it'll fail to return a result for some reason. Worst thing that could happen is stack overflow but it won't let you call this function. I think that RPC is fine as long as it's clearly separated and those who read and write code do not mask it behind ordinary innocent looking calls. It's OK to call personApi.getFullName(person.fistName, person.lastName). It's not OK to call person.getFullName().

Too 4y ago
Async functions, now available in many languages, solves many of the issues RPC had in its childhood. With the problem that you get "colored" functions. Thinking about it that's probably a good thing, because with RPC you had colored functions, except you didn't know about it, some innocent functions would just randomly take forever to return.
- mpweiher 4y ago
  No, they don't actually solve any of the problems. They just provide syntactic sugar papering over them and, what's worse, exactly make you believe that the problems have been solved.
  - olalonde 4y ago
    At least with "await person.getFullName()", it's more obvious that a network call is being made.
    - P5fRxh5kUvp2th 4y ago
      that's an abuse and an excuse. 1. It's an abuse of what async/await is. async/await is about concurrency and says NOTHING about the cause of that concurrency. 2. It's an excuse to rationalize what is clearly a bad idea. RPC should obviously be RPC. What seems obvious to you in that function call isn't going to be obvious in 5-10 years once your sensibilities are gone and it's someone else dealing with the crap you wrote.
- lelanthran 4y ago
  > Async functions, now available in many languages, solves many of the issues RPC had in its childhood. Like which problems? Transparency? Nope; the caller still needs to set up where the remote function resides, which of the multiple remote functions with that name must be executed, etc. Latency? It actually makes it harder - you now need separate plumbing so that calls which take more than $X minutes must be considered failure. Reliability? Not this one either - the error returned by a function will still have to be handled separately from an error returned by the network.
  - Too 4y ago
    Well, I think a fair presumption is that the option compared with is still distributed. Network latency and disruption is always going to be an inherent part of such. The comparison was more against rpc without async. Primarily, async exposes that the call you are dealing with goes over the network. You can no longer accidentally put a blocking rpc call in the UI thread. You can easily send multiple concurrent requests without fuzz. It has built in primitives to add timeouts on any call, even chained ones, without having to rely on complicated thread-watchdogs or checkpointing.
brillout 4y ago
Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions.

Too 4y ago

Async functions, now available in many languages, solves many of the issues RPC had in its childhood. With the problem that you get "colored" functions. Thinking about it that's probably a good thing, because with RPC you had colored functions, except you didn't know about it, some innocent functions would just randomly take forever to return.

mpweiher 4y ago
No, they don't actually solve any of the problems. They just provide syntactic sugar papering over them and, what's worse, exactly make you believe that the problems have been solved.
- olalonde 4y ago
  At least with "await person.getFullName()", it's more obvious that a network call is being made.
  - P5fRxh5kUvp2th 4y ago
    that's an abuse and an excuse. 1. It's an abuse of what async/await is. async/await is about concurrency and says NOTHING about the cause of that concurrency. 2. It's an excuse to rationalize what is clearly a bad idea. RPC should obviously be RPC. What seems obvious to you in that function call isn't going to be obvious in 5-10 years once your sensibilities are gone and it's someone else dealing with the crap you wrote.
lelanthran 4y ago
> Async functions, now available in many languages, solves many of the issues RPC had in its childhood. Like which problems? Transparency? Nope; the caller still needs to set up where the remote function resides, which of the multiple remote functions with that name must be executed, etc. Latency? It actually makes it harder - you now need separate plumbing so that calls which take more than $X minutes must be considered failure. Reliability? Not this one either - the error returned by a function will still have to be handled separately from an error returned by the network.
- Too 4y ago
  Well, I think a fair presumption is that the option compared with is still distributed. Network latency and disruption is always going to be an inherent part of such. The comparison was more against rpc without async. Primarily, async exposes that the call you are dealing with goes over the network. You can no longer accidentally put a blocking rpc call in the UI thread. You can easily send multiple concurrent requests without fuzz. It has built in primitives to add timeouts on any call, even chained ones, without having to rely on complicated thread-watchdogs or checkpointing.

brillout 4y ago

Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions.