Don't you think Kay Objects are very present in distributed microservices architectures? Services which provide APIs as the only way to interact. Some even requ

Don't you think Kay Objects are very present in distributed microservices architectures? Services which provide APIs as the only way to interact. Some even require consumers to register their own servers for callback and require the implementation of callback functions. Without going much further Server-Client architecture presents characteristics of Kay objects, if only because their physical separation requires limitation of the control between server and client for security concerns. Multitenancy of machines also forwarded Kay Objects in parallel due to security concerns, first OS processes and then stricter virtual machines enforced independency of these objects and allowed communication through strict long-range protocols like TCP in the case of VMs. I feel Kay pushed for objects at the application level and this was largely redundant with Operating system level concepts like scheduling, user and kernel layer memory protection. Threads and containers proved that there is a need for a more tightly controlled scheduler and resource sharing, but in general Kay's objects nowadays just use strong encapsulation mechanisms at the OS layer such that objects usually communicate via network protocols as if they were in separate machines altogether, they truly are separate physical objects running independently. It is important to consider the ideas of Kay in their time context, preemptive scheduling was a young concept, and processes back then did not have much protection against memory accesses. Of course the scarcity of resources (compute, memory) back then was also a factor to push for application level encapsulation, but nowadays we can just spin up virtual machines and throw metal into some datacenters, there is a surplus of hardware so there is no incentive to replicate and optimize hypervisors, so they don't move to the application layer at all. Turns out all of those security features are really important in guaranteeing encapsulation, you don't even have to worry about whether there is a bug leaking state, because that is taken as a security concern, and the barriers are designed to be protected against skilled attackers, so random bugs are much less likely to break encapsulation. Application level objects are still very much used, to my knowledge in simulation software including games, where it would be unreasonable and unnecessary to spin up a VM for each butterfly in a simulated world. But it turns out that in business, Kay Objects are usually assigned to a programmer or to a team of programmers, so there's rarely situations where a programmer is in charge of more than one object, and they need to play a dissociated god controlling designing many entities, and when we do, we inevitably suffer from an identity crisis. And we use harder abstractions like processes or servers anyways. No need to fit multiple kay objects into a single process, that usually causes way too many objects. It's desirable to assign some cost and administrative overhead to object creation to avoid Programmer Ego Death.