Jonathan Blow

I would say it's even the name, "language *server* protocol". The objection is that there is absolutely no reason for that to be exposed as a server, HTTP-server with JSON-RPC no less. Could you even imagine how complex this would be if you made it into 5 servers communicating

amongst themselves? I sincerely hope you can appreciate the danger of an entire generation believing that replacing something so fundamental and simple as synchronous function calls with asynchronous HTTP-requests to a JSON-RPC HTTP-server is somehow desireable and good. It's not

The one thing I didn’t mention in the talk, too, is that once you have N servers, the claim “this insulated your program from a crash” is clearly untrue, because have fun trying to recover when some guy in the middle of that web dies and restarts.

If they are stateless (caching aside), crashing/restarting can be a way of life. And there is no "web" implied - what is the need for communication between servers?

Because libraries use libraries, all the time. I explain this in the talk. It's easy to say "stateless", but try the actual exercise of looking at every API you use and seeing what would be required to make it stateless, and what would be the corresponding drop in efficiency.

(And also, what would be the corresponding increase in complexity of the control logic.)

If your API is designed for potentially high latency (which is a good practice in many cases anyways), and you have a language-native client that wraps the IPC, there is no reason writing client code would be more difficult to write.

However the server code would be much more complicated to write. It's also much more complicated to debug and reason about from the perspective of the client. Additionally, the OS must task switch to the server process which in itself has a significant latency and cost, and back.