Might've fact-checked this article after letting Claude write it... Erlang processes are in no way what's commonly called "persistent" - there's no way to pers

Might've fact-checked this article after letting Claude write it... Erlang processes are in no way what's commonly called "persistent" - there's no way to persist them automatically (ie. freeze to disk and wake later). It's even preferred to either use external databases like Mnesia or manually implement persistence in the actor itself for robustness. The only even slightly mainstream persistent environment is Smalltalk with its images. For Linux there's also CRIU, but that has quite a few caveats. If the definition of "persistent" is "processes run until they're done or they crash", well, pretty much everything fulfils that, so the distinction is meaningless. > "You can send messages to a process from a terminal, from another process, from a web socket, from anywhere." Also technically wrong. This only works if you have a cluster of erlang nodes already set up in full mesh mode. It's not auto-discoverable, scalable, P2P or anything remotely like that. If you want that, it's outside the Erlang stdlib. Websockets etc. need to be manually proxied. There's no standard protocol, security boundary or anything... Ugh, actually I give up, there's too many mistakes to even go into. Final opinion: slop.