Erlang processes and Java threads

I'm reading "elixir in action" book by SA š a Juri ć, And in the first chapter:

Isn't that true for Java threads? I mean, when a java thread crashes, it doesn't crash other threads - especially if we're looking at the request processing thread (let's exclude the main thread from this discussion)

Solution

Repeat after me: "these are different examples"

Say it out loud about 20 times - that's our current mantra

If we really have to compare apples and oranges, we should at least consider where the common aspects of "results" intersect

Java "object" is the basic unit of calculation for Java programmers In other words, an object (basically a structure with arms and legs, with encapsulation somewhat more strictly enforced than in C + +) is the main tool you use to simulate the world You think "this object knows / has data {x, y, Z} and executes functions {a (), B (), C ()} on it, carries data anywhere, and can communicate with other objects through calls. Functions / methods are defined as part of their common interface. It is a noun, and nouns are things "That is, you can determine the thinking process around these units of calculation. By default, what happens between objects happens in sequence, and a crash will interrupt the sequence. They are called" objects ", so (if we ignore the original meaning of Alan Kay), we get" Object-Oriented "

Erlang "process" is the basic unit of calculation for Erlang programmers Processes (basically independent sequential programs running in their own time and space) are Erlang's main tool for modeling the world (1) Similar to how Java objects define encapsulation levels, Erlang processes also define encapsulation levels, but in the case of Erlang, computing units are completely isolated from each other You cannot call a method or function on another process, access any data in it, run in the same timing context as any other process, and cannot guarantee that the relevant message receiving order is to other processes that may be sending messages They may also be completely different planets (and, thinking of it, it's actually reasonable) They can crash independently of each other, while other processes will only be affected if they deliberately choose to be affected (even if this involves messaging: basically, registering to receive a suicide note from the death process itself does not guarantee that it will arrive in any form, and you may or may not choose to respond relative to the order of the whole system)

Java deals directly with complexity in composite algorithms: how objects work together to solve problems It is designed to perform this operation in a single execution context, and sequential execution is the default in Java Multiple threads in Java represent multiple running contexts and are a very complex topic, because the influence activities in different timing contexts affect each other (and the whole system: therefore, defensive programming, exception scheme, etc.) In Java, "multithreading" means something different from Erlang. In fact, it is not even said in Erlang, because it is always the basic situation Note that Java threads imply time-dependent isolation, not memory or visible references - manually controlling visibility in Java by selecting private and public content; The universally accessible elements of the system must be designed as "thread safe" and reentrant, sequenced through queuing mechanism, or locked In short: scheduling is a manual management problem in threaded / concurrent Java programs

Erlang separates the running context of each process according to execution time (scheduling), memory access and reference visibility. This can simplify each component of the algorithm by completely isolating the algorithm This is not only the default case, but also the only case available under this calculation model The cost of this is that once a part of the processing sequence passes through the message barrier, the order of any given operation will never be known - because the message is essentially a network protocol, and there is no method call to ensure that it is executed in a given internal context This is similar to creating a JVM instance for each object and only allowing them to communicate across sockets - which can be very troublesome in Java, but Erlang's design method works (by the way, this is also the basis of the concept) to write "Java microservices". If one abandons the networking burden of buzzwords - by default, Erlang programs are groups of microservices It all depends on trade - offs

These are different examples The closest thing we can find is that from a programmer's point of view, Erlang processes are similar to Java objects If we have to find something to compare Java threads... Well, we won't find anything similar in Erlang at all, because there is no such comparable concept in Erlang Defeat the dead horse: These are different examples If you write some nontrivial programs in Erlang, this will be obvious

Please note that I said "these are different examples", but I didn't even cover the topic of OOP and FP The difference between thinking in Java and thinking in Erlang is more important than OOP and FP

Although Erlang's "concurrency oriented" or "process oriented" basis is indeed closer to Alan Kay's idea when he coined the word "Object-Oriented" (2), this is not the real focus Kay's result is that by cutting your homogeneous body into discrete blocks, the cognitive complexity of the system can be reduced, and isolation is necessary Java implements this in a basically still procedural way, but the structural code revolves around a special syntax rather than high-order scheduling closures, called "class definitions" Erlang achieves this by splitting the running context by object This means that things in Erlang cannot call methods to each other, but things in Java can This means that Erlang things can crash in isolation, but Java things can't There is a lot of impact from this basic difference - so "different paradigms" balance.

Footnote:

>By the way, Erlang implements the version of "the actor model", but we don't use this term because Erlang predates the popularity of the model Joe didn't realize this when he designed Erlang and wrote his thesis. > Alan Kay has said a lot about what he mean when he coined the term, The most interesting is his take about message passing (one-way notification from an independent process with its own time and memory to another) vs call (function or method call in sequence) with execution context of shared memory) – and how to blur a little between the programming language and the programming interface presented by the following implementation