> I'll stand by my ets comments though because it would be confusing to think of ets as not having to be wrapped in a process (for lifetimes if nothing else)
The point was that "ets" doesn't break isolation and doesn't logically behave any differently than as if inside it was wrapping a process and every lookup or update was behind the scenes sending a message to the process to read its data and returning a response. So the original poster's claim that somehow defaults to "sharing memory" are simply untrue. They just don't understand how it works, which is fine. I suspect they don't really use it that much and just found whatever they could by Googling it (pun intended as they are a Technical Program Manager).
Also, here is Robert Virding, one of Erlang creators, explaining it a lot better https://stackoverflow.com/a/1483875:
> ETS more or less behaves as if the table was in a separate process and requests are messages sent to that process. While it is not implemented with processes that the properties of ETS are modeled like that. It is in fact possible to implement ETS with processes. This means that the side effect properties are consistent with the rest of Erlang.
