Again, you don't need HTTP for that either. The GP's proposal achieves exactly the same thing.

IPC (networks, FIFO, pipes or whatever) decoupled services solve problems more on the ops side, from binary compatibility to resource segregation. They do very little on the dev side.

Of course you don't need it technologically speaking. Between DNS and SSL and stuff like openAPI, HTTP comes with a lot of baggage that is redundant when used on the back end.

My point is that it's not a technology problem in the first place. It's a problem of clashing senses of style and taste. It's a culture problem. If you need to dress up your culture problem fix with a technology explanation, http is the way to go because it's widely understood and so boring that nobody is going to ask you to explain it in too great of detail.

So, I have to disagree again.

Your language's module system is boring. An specialized web server is about as close to the opposite as a corporate structure will allow.

One of HTTP's biggest strengths here are that it's essentially perfectly language-agnostic (in practice, not just theory) and it lets you solve basically all networking problems (hardware and software) in normal, off-the-shelf, trivial-through-Google-scale ways without having to change it. And if you want to build something custom, there are more experts and documentation and examples than any other system.

I agree it's suboptimal for performance. But it absolutely cannot be beat for business stability and flexibility. And your IPC costs generally do not dominate your request times anyway.

Yeah, I think this is the realistic answer. Technical solution to a social problem etc