Jonathan Blow

No, I never even addressed your thesis. I just pointed out that you take a very uninformed standpoint on sth and explain it wrongly and with extreme rhetoric ("devil", "the worst") so that it fits your narrative. Reminds me of certain people + makes it hard to take you seriously.

Also, your dismissive and partly immature tone here reinforces my impression to not take you seriously, even though I think you give some interesting points in your talk. Still, I don't get the feeling that you are interested in a meaningful discussion. That's fine, so long.

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