3 ms·

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. Thinkin

by 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.

by Too 4y ago

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.