Microservices are different from language abstractions (classes, etc.) In two important ways:
1. More decoupling means you can use an entirely different langauge
2. Services can be deployed, restarted, etc. independently.
But that comes with disadvantages. The contract then becomes message passing and serialization/deserialization, which is fairly primitive. You can't pass functions/callbacks, and simple static checks become a whole validation problem. It also limits your ability to use interesting types across services.
The XML craze 20 years ago tried to tackle all of these problems (remember XML schemas?), but it became unweildly and didn't really succeed despite a huge enterprise push.
It certainly can be. Sometimes you start in one language but then need to integrate with something else that really only works well with a different language.
1. More decoupling means you can use an entirely different langauge
2. Services can be deployed, restarted, etc. independently.
But that comes with disadvantages. The contract then becomes message passing and serialization/deserialization, which is fairly primitive. You can't pass functions/callbacks, and simple static checks become a whole validation problem. It also limits your ability to use interesting types across services.
The XML craze 20 years ago tried to tackle all of these problems (remember XML schemas?), but it became unweildly and didn't really succeed despite a huge enterprise push.