[rdtsc]

> But an escape hatch is still an escape hatch. These mechanisms bypass the process isolation model entirely. They are shared state outside the process model, accessible concurrently by any process, with no mailbox serialization, no message copying, no ownership semantics. And when you introduce shared state into a system built on the premise of having none, you reintroduce the bugs that premise was supposed to eliminate.

No, they do bypass it. I don't know what "Technical Program Managers at Google" do but they don't seem to be using a lot of Erlang it seems ;-). ETS tables can be modeled as a process which stores data and then replies to message queries. Every update and read is equivalent to sending a message. The terms are still copied (see note * below). You're not going to read half a tuple and then it will mutate underneath as another process updates it. Traversing an ETS table is logically equivalent to asking a process for individual key-values using regular message passing.

What is different is what these are optimized for. ETS tables are great for querying and looking up data. They even have a mini query language for it (https://www.erlang.org/doc/apps/stdlib/qlc.html). Persistent terms are great for configuration values. None of them break the isolated heap and immutable data paradigm, they just optimize for certain access patterns.

Even dictionary fields they mention, when a process reads another process' dictionary it's still a signal being sent to a process and a reply needing to be received.

* Immutable binary blocks >64B can be referenced, but they are referenced when sending data using explicit messages between processes anyway.

[dnautics]

minor nitpicks:

ETS is not a process that responds to messages, you have to wrap it in a process and do the messages part yourself.

Process dictionary: i am pretty sure that's a process_info bif that directly queries the vm internal database and not a secret message that can be trapped or even uses the normal message passing system.

[rdtsc]

> ETS is not a process that responds to messages, you have to wrap it in a process and do the messages part yourself.

I didn't say it's implemented as a process but works as if it where logically. Most terms (except literals and the binary references) are still copied just like when you send message. You could replace it behind the scenes with a process and it would act the same. Performance-wise it won't be the same, and that's why they are implemented differently but it doesn't allow sharing a process heap and you don't have to do locks and mutexes to protect access to this "shared" data.

> i am pretty sure that's a process_info bif that directly queries the vm internal database and not a secret message that can be trapped or even uses the normal message passing system.

I specifically meant querying the dictionary of another process. Since it's in the context of "erlang is violating the shared nothing" comment. In that case if we look at https://www.erlang.org/doc/system/ref_man_processes.html#rec... we see that process_info_request is a signal. A process is sent a signal, and then it gets its dictionary entries and replies (note the difference between messages and signals there).

[dnautics]

ah sorry you did indeed write signal and somehow my brain read it as "message". 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)

[rdtsc]

> 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.