Erlang Beginner: Some features of Erlang and a summary of personal understanding _erlang

My understanding of the Erlang programming philosophy is to write code in the context of a distributed architect.

Functional programming

The function in Erlang is the function in mathematics: there must be a return value. As long as a function must have a return value, the function is a procedure in which the period in English is a function terminator. The expression before the end of the function is the return value of the function. So that's why the functions in Erlang don't see any return statements. Functions and functions in other languages, such as C + +, can be passed through shared variables. The functions in Erlang are not allowed, and messages are passed in and out of the function. It's also just why Erlang is inherently parallel, because they don't share variables, and they don't need locks.

Many people hear that functional programming can be tall or obscure. Because the function is programmed without a For loop statement, it seems to me that the key is to iterate through it using "list down" and "tail recursion". When it comes to functional programming, you get a quick sort of thing, and the following example is a quick sort of Erlang version:

Copy Code code as follows:

-module (sort).

-export ([QSORT/1]).

Qsort ([])-> [];
Qsort ([Pivot | T])->
Qsort ([X | | x <-T, x < Pivot]
+ + [Pivot] + +
Qsort ([X | | x <-T, x >= Pivot]).

Very concise, [Pivot | T] is to take the first element of the list as a Pivot in the fast row.

Copy Code code as follows:

[X | | x <-T, x < Pivot]

The upper form is "list derivation", meaning to find out that all elements in list T are less than Pivot and make a new list. However, this example obviously does not have a high performance, just an example.

Many people have been advocating that the functional language will soon usher in the sun, but in my opinion, functional programming can only be a small number of languages, this is like the Lisp Machine, was advocated by the hype or died. Now the mainstream of the computer architecture is Neumann system, is not the most suitable for functional language survival of the soil.

Everything is constant.

Without variables, there is no competition for resources through variable shared state, and there is no need to lock. Any state changes are made through the input and output of the function, and the state change of the lightweight process is realized by message passing (the input and output of the function). That's why some people say that functional programming is good for high concurrency because they don't have variables and everything is constant.

Lightweight process

Erlang has a spawn function that allows you to quickly create a process that is not the operating system, but Erlang's own lightweight process. Erlang lightweight to beyond your imagination, when building a KV database, you can even assign different key to different processes. And the process of the representation unit is PID, as long as the process of knowing the PID, even if the process is on top of other machines, can be easily sent to it. The reason is Erlang's "Born with RPC communication" and "self-port mapping"

Born with RPC communication

Copy Code code as follows:

Topid! Data

Topid is the ID of the recipient process, and Data can be any type of Erlang, such as

Copy Code code as follows:

Pid! {name, ' Jb51.net '}.

That is, any data structure can be sent directly as a message, born with RPC communication. (Although originally RPC meaning is "Remote procedure call", but in fact is to help you serialize the data structure, Erlang's!) The same is true for operators. ）

Process Port Mapping

Messages between nodes are also represented in the code

Copy Code code as follows:

Topid! Data

That is, when writing code, there is no need to think about which machine the process is on, whether this Erlang process (where the process is an operating system-level process, not Erlang's lightweight process), or any other machine process. This is because of the existence of a EPMD.

EPMD is the abbreviation for Erlang Port Mapper Daemon, which is equivalent to DNS in Erlang clusters, providing node name to port queries, EPMD bound to the 4369 ports that are generally known.

With EPMD, writing a distributed program is as simple as writing a stand-alone program.

Strict modular management

Erlang's modules are similar to the namespace (namespaces) in C + +, but more efficient software engineering management than namespaces.

The following code is visible everywhere in the Erlang project source.

Copy Code code as follows:

-module (My_app).
-export ([START/2, STOP/1]).

-module indicates the module name,-export indicates the exported function. Functions that have not been exported cannot be invoked by the outside world. From the perspective of software engineering, this makes the function of the module and the use of the method clearer. The user only needs to care about how to-export the inside function. Compared to C + + is particularly irregular in this regard, and Java by declaring classes as public class to indicate that it can be used outside, Node.js is also using export to display declarations can be used outside the function.

Behavioral patterns

Copy Code code as follows:

-module (Ecomet_app).

-behaviour (application).

% comment:application Callbacks
-export ([START/2, STOP/1]).
-behavior (application).

The concept of "behavioral pattern" inside ERLANG/OTP is equivalent to the interface concept within OOP. The code example above means that the module (ECOMET_APP) adheres to the behavior pattern (application). The two interface functions that need to be implemented in a rigid behavior pattern are-export ([START/2, STOP/1]). 。

Another example is the compliance Supervisor (supervisor) behavior pattern, and the implementation of an interface function is-export ([INIT/1]). 。

Copy Code code as follows:

-module (Ecomet_sup).

-behaviour (supervisor).

% Supervisor Callbacks
-export ([INIT/1]).

Supervisor Mechanism

The innate distributed nature of ERLANG/OTP is well reflected in the monitoring mechanism, where each OTP application is started as a supervisor (supervisor) and worker (worker). Their relationship is a tree structure, each worker's superiors will have supervisors, each supervisor's superiors may also have supervisors. When the worker exits unexpectedly, the supervisor decides whether to restart the worker according to the corresponding parameters. If the reboot fails, the supervisor will also quit, and the more senior supervisors will receive the signal and then restart them for processing. This watchdog mechanism is very well understood, in fact, is the try in OOP programming ... catch exception handling mechanism. When an exception occurs, one layer at a time is thrown upwards until someone restarts it.

OTP Platform

The most powerful place in Erlang is the most difficult place to learn, the OTP platform. A variety of behavioral patterns, let me feel like many years ago when learning MFC, feel very powerful, but always feel that they are pressed to death in a specific track running, a kind of not free fatigue.

Code eagerly swapped

Hot switching is also called Hot upgrade, and in most cases you need to restart the process if you need to upgrade the C++/java program process version. Erlang's support for hot switching means that code upgrades can be done at run time. The upgrade process does not affect the running of processes, and the old and new versions can coexist during the transition phase. It's not a bunker. This is a powerful feature for those services that require 7x24 high availability.

The Erlang process itself can be viewed in real time by a console like "backdoor", or even directly using the console to modify the configuration, which is erl for most other languages.

Typical disadvantage

1. There are too few documents, and there are fewer answers to the problem search.
2.Erlang talent Scarce, recruitment is not easy.
3. Dynamic language is the most typical debugging is not easy.
4. The threshold of entry is higher.

Finally, I'm just an entry-level beginner in Erlang, because I need to use Ejabberd (Erlang's Open source project) to learn about Erlang and lack of combat experience, so this article is titled "Erlang First Experience."