It seems that your first two points are an argument against synchronous RPC.
These days asynchronous functions are frequently used in-process, so RPC calls that use the same async abstractions seem appropriate.
I guess the historical background is that the RPC syntactic sugar implied sync calls.
Regarding your last point, there is no reason why a language level RPC implementation cannot map to TLS/HTTP/JSON as the transport layer and encoding.
The real issue with RPC is that only a small subset of all the types supported in a language can be sanely supported, and it just ends up being syntactic sugar for message passing plus matching of replies to requests. There is nothing wrong with this, but it is indeed a leaky abstraction.
Yes - I see other posters trying to spin the article to make it only an argument against "old" RPC solutions (CORBA I guess?). This seems to be an attempt to leave an escape hatch for their pet RPC solutions that happen to be more modern.
When I first joined my workplace, some of the resident engineers were overly disposed to cargo culting google practices. I had a robotics application that just screamed for using something like ROS, but I was encouraged to use gRPC to underpin these microservices. I was inexperienced enough to assume they knew something I didn't, but I kept scratching my head trying to figure out why this was supposed to be better than a simple pub-sub system. It felt like a huge impedance mismatch with what was actually happening at the message level. When I asked myself whether I could use gRPC in a simpler, pub-sub-like mode, I instead found a bunch of janky projects where people were trying to build pub-sub on TOP of gRPC (?!) It wasn't until later when some of the cargo-culters left and new folks with a robotics background joined the company that I realized I had been right all along.
Reading this article was cathartic because it expressed a truth I didn't know I was allowed to think - I don't _want_ a procedure-like interface! It is simultaneously simpler and more correct to think in terms of message-oriented IPC. RPC seems to be about letting people think in a lazy away about how their distributed application works... but you inevitably end up saddling them with a long tail of things that were brushed under the rug.
Not CORBA - RPC preceded it by at least a decade (at least on Unix and possibly VMS). You defined an interface using a description language (XDR) which generally produced both client and server code. edit: there was also a utility "rpcgen" that automated a lot of stuff.
The generated code looked after all the marshalling/unmarshalling of your types, did the connection handshaking etc. You had to have a service running on your Unix machine (rpc.bind?). NFS used to use XDR and some variant of RPC to work but I am not sure it does any more.
> NFS used to use XDR and some variant of RPC to work but I am not sure it does any more.
Yep, still does [1]. Even 4.1 and 4.2 (the most modern variants of NFS) all start with .x files and XDR encoding. The ancient names codified by Sun still exist and still work (and the tooling still works for introspection as a nice bonus).
I guess the whole Sun set of tools was built on RPC: All the yellow pages stuff, automounting your home directory etc. Never really thought about it too hard when I was a Sun administrator back in the 1990s.
If somebody gave me a choice of CORBA or Sun RPC, I'd still pick Sun RPC. CORBA was a nightmare.
I guess the historical background is that the RPC syntactic sugar implied sync calls.
Regarding your last point, there is no reason why a language level RPC implementation cannot map to TLS/HTTP/JSON as the transport layer and encoding.
The real issue with RPC is that only a small subset of all the types supported in a language can be sanely supported, and it just ends up being syntactic sugar for message passing plus matching of replies to requests. There is nothing wrong with this, but it is indeed a leaky abstraction.