erl_0020 "Building a reliable distributed system in the face of software errors" Reading notes 001 "for concurrent COPL"

In the real world, sequential (sequential) activities are very rare. When we're walking down the street, we'll be amazed if we see only one thing happening, and we expect to encounter many simultaneous activities.

If we cannot analyze and predict the results of the numerous events that occur simultaneously, then we will face enormous dangers, such as driving the task we will not be able to complete. The fact that we can do things that need to deal with a lot of concurrent information also suggests that we have a lot of perceptual mechanisms that allow us to instinctively understand concurrency without having to think consciously.
For computer programming, however, the situation suddenly becomes the opposite. Arranging activities into a sequential chain of events is considered to be a norm, and it is thought that in a sense it is simpler, and that scheduling a program into a set of concurrent activities is avoided as much as possible and often considered difficult.
I believe this is due to the lack of strong support for real concurrency in almost all traditional programming languages. The vast majority of programming languages are inherently sequential, and all of the concurrency in these programming languages is provided only by the underlying operating system, not by the programming language. In this paper, I present a world in which concurrency is provided by programming languages, not by the underlying operating system. I refer to languages that provide good support for concurrency as concurrency-oriented languages (Concurency oriented Language), referred to as COPL.

COPL can be characterized by the following 6 features:
1. The COPL should support the process. Each process should be considered as a self-contained virtual machine (self-contained).
2. Each process running on the same machine should be highly isolated. A failure in one process cannot cause side effects on other processes unless the interaction is explicitly defined in the program.
3. Each process must be identified with a unique, non-patterned identifier. We call the Pid of the process.
4. There is no shared state between processes. The process interacts only with message delivery. As long as you know the Pid of the process, you can send a message to it.
5. Message delivery is considered unreliable and is not guaranteed for transmission.
6. One process should be able to detect failures in another process and be aware of the cause of the failure.
It is important to note that the concurrency provided by COPL must be true concurrency, so objects that exist in the form of processes are truly concurrent, and interprocess messaging is a true asynchronous message, unlike many object-oriented languages that are passed through a remote procedure call (the remotes procedure Call) to impersonate.

erl_0020 "Building a reliable distributed system in the face of software errors" Reading notes 001 "for concurrent COPL"