You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't.
> The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible
Yeah, that's the idea. "defense in depth".
> And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war.
(1) not all attackers are internal
(2) some attackers are internal and many very profitable organizations do restrict employee access to secrets (and in many cases this is required by compliance).
As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible.
As for memory being shared among processes, it's not only not impossible but quite common in performance-sensitive applications. https://man7.org/linux/man-pages/man7/shm_overview.7.html
> many very profitable organizations do restrict employee access to secrets
For one, code is not secret. Secondly, when was this discussion scoped to profitable organizations? A very, very large chunk of HN readers work in startups.
> in many cases this is required by compliance
This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith.
