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

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

Not just I-Ready. This is the majority of educational software.

The stupid repetitive animations. I am sure they sold it to some administrators as being "fun", and "kids are going to love it" because, see, there is a cute penguin doing a 10 second dance. But of course you have to watch the animation after each section and you can't skip ahead.

The kid makes a single mistake, and the "smart adaptive" algorithm throws them back to the preschool school level to "let's start with numbers again", while the kid just clicked the wrong button because the UI is janky and because they are angry with stupid penguin who is getting on their nerves.

Some teachers understand what's going on refuse to use this stuff and print actual paper and pencil tests and homework sheet. But that only works until the standardized tests come, those are all on the computer usually, with the same janky UI.

They are just covering all the market segments. This is for people who didn't want to shell out $1000 for a laptop for their kid, or have another one just to browse the web. Or they have an iphone but not a mac laptop, but now they might want one cause it's even cheaper than a phone. This will be pushed into schools probably as well.

Yup I don’t see any huge downsides here for these companies, and not much incentive to change. The more it happens the more they can point to each other and say “see, it’s not just us”