I don't dispute one might want to have this control. At the same time, I don't see a theoretical reason one can't have the same programming model, and choosing what computation runs local vs. distributed is just a configuration. A function call or a remote call won't change the domain logic, it's an implementation detail - but today, this leaks into all kinds of decisions, starting from microservices and working backwards to glue everything together again.

The programming model is fundamentally different between local vs distributed. Imagine if every local function call in your monolith significantly increased in error rate and latency. Your optimal algorithms would change - you can't just loop over a network call like you can with a local function call. That's what happens when you take a local invocation and put it across a network boundary. The probability of things going wrong just goes up.

I'm not proposing to code like a monolith - but I don't see a reason there can't be a programming model that unifies that.

APIs like Spark, for instance, make it largely transparent - processes are scheduled by the driver in nodes w/ hot data caches, and processes that fail are transparently retried; and yet this doesn't impact how you write your query. Effects systems are another thing can help us reason around i/o as function calls and handle the fail-ability.

I would bet it's a matter of lacking good accepted patterns instead of a theoretical impossibility.

It's not a theoretical impossibility: you can wrap every function call in a monad today if you want. It's just a practical nightmare.

It's way more than "just a configuration".

> A function call or a remote call won't change the domain logic

Understanding performance and minimizing failure modes and their impact on larger systems makes for a whole career as "SRE". Making remote calls all over a codebase creates behaviors that are practically impossible to debug or optimize. But the blocker is the network impact of large applications and the emergence of cascading failures.

This point is what so many miss. The conceptual decomposition seems nice, but the physical implications of that decomposition are horrible. The further you split a function caller from its caller, physically, the more chaos you're asking for. It's quite simple to see from a physical perspective but from an abstract perspective it's all lines and boxes.