When I started programming, linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.
Microservices architectures are like the Navy using nuclear reactors to power aircraft carriers. It’s really compelling in certain circumstances. But it comes with staggering and hard to understand costs that only make sense at certain scales.
There is really something to be said about using C as a teaching language. When you start with C, the entire process is laid bare. And fully agree with earlier observation that microservices are delegating the 'link' phase to a distributed operational/runtime regime. Just being able to see that (conceptually) would steer away a mature team from adopting this approach unless absolutely necessary.
One of the patterns that I have noted in the past 3 decades in the field is that operational complexity is far more accessible than conceptual complexity to the practitioners. Microservices shift complexity from conceptual to operational. With some rare exceptions, most MS designs I've seen were proposed by teams that were incapable of effective conceptual modeling of their domain.
I'm not sure why you are being down voted. In context of calling business logic we have moved away from linking.
I guess the context is only implelied in your parent post.
The rise of the network API in the last 20 years has proven it's own benefits. Whether you are calling a monolith of a microservice, it's easier to upgrade the logic without recompiling and re-linking all dependencies.
I think there's too much being conflated to make such a statement.
For example, microservices tend to communicate via strings of bytes (e.g. containing HTTP requests with JSON payloads, or whatever). We could do a similar thing with `void` in C, or `byte[]` in Java, etc.
Languages which support 'separate compilation' only need to recompile modules which have changed; if all of our modules communicate using `void` then only the module containing our change will be recompiled.
It's also easy to share a `void` between modules written in different languages, e.g. using a memory-mapped file, a foreign function interface, etc.
It's also relatively* easy to hook such systems into a network; it introduces headaches regarding disconnection, packet loss, etc. but those are all standard problems with anything networked. The actual logic would work as-is (since all of the required parsing, validation, serialisation, etc. is already there, for shoehorning our data in and out of `void*`).
If these benefits were so clear, I would expect to see compiled applications moving in this direction. Yet instead I see the opposite: stronger, more elaborate contracts between modules (e.g. generic/parametric types, algebraic data types, recursive types, higher-kinded types, existential types, borrow checkers, linear types, dependent types, etc.)