3 ms·
This is an excellent summary of rationale for Erlang with the goals stated at the beginning of the article! However, the Erlang language itself is now rather
by ProfHewitt 6y ago
This is an excellent summary of rationale for
Erlang with the goals stated at the beginning of the article!
However, the Erlang language itself is now rather dated :-(
In order to implement next generation Universal
Intelligent Systems [Hewitt 2019], the following extensions
to Erlang are needed:
• Automatic reclamation of processes. For example,
Erlang uses Process Identifiers (PIDs) to communicate between
processes. However, a process that has a process identifier
(say ProcessIdentifier) of a process with which it
communicates can launch a denial of service attack to kill
that process using exit(ProcessIdentifier, kill). An Erlang
process can be orphaned if its Process Identifier (PID)
becomes inaccessible. By default, the send operation in
Erlang always succeeds (even if the target is a non-existing
process).
• Strong parameterized types with no type Any.
• Region of mutual exclusion for an Erlang process.
An Erlang process does not have a region of mutual exclusion,
which can lead to internal conflicts within processes.
• Behavior change using variables in a region of mutual
exclusion instead of having to create auxiliary processes to
hold state with callbacks. [Swain 2014] In particular,
o Better support for holes in the region of mutual exclusion
of an Actor implementation. For example, in Erlang it is
necessary for application programmers to explicitly code a
request handler for each re-entry into the region of mutual
exclusion potentially enabling cyberattacks from outside the
process.
o Better ways to upgrade Actors in place without losing work in progress.
- al2o3cr 6y ago"However, a process that has a process identifier (say ProcessIdentifier) of a process with which it communicates can launch a denial of service attack to kill that process" The BEAM does not promise (or provide) secure isolation between processes within a single VM. It's even called out in their bug report policy: https://github.com/erlang/otp/wiki/FAQ:-What-kind-of-patches-will-be-approved%3F#can-i-write-a-patch-to-increase-the-security-of-the-erlang-distribution https://github.com/erlang/otp/wiki/FAQ:-What-kind-of-patches... "An Erlang process does not have a region of mutual exclusion, which can lead to internal conflicts within processes." I don't follow the use of "mutual exclusion" in this statement; the only thing that can write to a process's stack or heap is the process - what kind of "conflicts" do you mean? "For example, in Erlang it is necessary for application programmers to explicitly code a request handler for each re-entry into the region of mutual exclusion" This sentence doesn't help either, because the previous statement was that the processes don't _have_ the region this objects to writing handlers for entering...
- ProfHewitt 6y agoIn general, an Actor receiving a message enters its region of mutual exclusion (which can have holes), which is explained here: https://papers.ssrn.com/abstract=3459566 https://papers.ssrn.com/abstract=3459566 Is there a rigorous formalization of Erlang message passing?
- dnautics 6y agoI think Prof. Hewitt should one of these days actually write a working system in Erlang or Elixir. I suggest to Carl that he write something easy (and potentially useful), like a DNS server, as a starting point. Raft might also be fun, that's about 350-500 lines to do as it is in the paper, and maybe about 600 with the upgrades necessary to get a correct consensus protocol.
- ProfHewitt 6y agoThere are a number of very useful systems written for BEAM! Consensus protocols are too slow for Universal Intelligent Systems (UIS) :-( See the following for UIS: https://papers.ssrn.com/abstract=3428114 https://papers.ssrn.com/abstract=3428114
- dnautics 6y agoYeah but have you written one? Give it a shot sometime. It's fun, I promise. You'd be surprised at how far an imperfect actor system can go and how easy actors (or in this case accidental-almost-actors) makes things!
- ProfHewitt 6y agoThe Actor paradigm is indeed very powerful. It has been reinvented many times since it was first published in 1973. For example, Erlang was a reinvention that put the paradigm into many practical applications :-) However, only more recently has it been characterized up to a unique isomorphism. See the following article: https://papers.ssrn.com/abstract=3459566 https://papers.ssrn.com/abstract=3459566 The most important code to be written now is for the foundations of Universal Intelligent Systems :-)