If somebody is only familiar with mainstream technology they would never expect the notion of fault resilience (rather than bare bones micro-level fault handling) to be part of a programming language.
Most high level programming languages are designed “language first” to perform computations. I suspect Erlang and the BEAM were developed in lockstep for computation and coordination which is why runtime concepts like process links and monitors are part of the core.
Designing for Scalability with Erlang/OTP p.175:
This forms part of the supervision strategy of a system and in some situations is put in place not by the developer, who focuses only on what particular workers have to do, but by the architect, who has an overall view and understanding of the system and how the different components interact with each other.
There also seems to be a drive to commoditize developer skills and designing for fault resilience seems to require a more advanced skill set. So the responsibility is pushed to the next level up, outside of the container. At this level of granularity the container becomes the “component”, k8s adopts the “let it crash” philosophy, creating design pressures to have the “component” no larger than what you can afford to lose.
At least that is my current perception …
