My understanding of Erlang's programming philosophy: writing code from the perspective of a distributed architect.
Functional programming
The functions in Erlang are functions in mathematics: there must be a return value. As long as a function must have a return value, a function is a process, with the period in English as the function ending character. The expression before the end of the function is the return value of the function. So this is also the reason why the functions in Erlang do not see any return statements. Functions and functions in other languages such as C++ can be previously passed through shared variables. The functions in Erlang are not allowed, and the message is passed through the function in and out. It's just the reason why Erlang claims to be natural and parallel processing, because they don't share variables, so they don't need to add locks.
Many people will find functional programming high-end or obscure. Because functions are programmed without for loop statements, but in my opinion, the key is to use [list implosion] and [tail recursion] to perform loop traversal. When it comes to functional programming, we will talk about quick sorting. The following example is the quick sorting of Erlang version:
-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 use the first element of the list as Pivot in the quick row.
[X || X <- T, X < Pivot]
The above formula is [list deduction], which means finding out all elements in list T are smaller than elements in Pivot to form a new list. However, this example obviously has low performance, just an example.
Many people have been advocating that functional languages are about to usher in the rising sun, but in my opinion, functional programming can only be a niche language. This is just like the lisp machine in the past, and it was advocated for a long time but it died. The mainstream computer architectures are now based on the von Neumann system, and are not the most suitable living soil for functional languages.
Everything is a constant
Without variables, there is no resource competition caused by variable sharing state, and there is no need to add locks. Any state changes are changed through the input and output of the function, and the state changes of lightweight processes are also realized by message passing (the input and output of the function). This is also why some people say that functional programming is suitable for high concurrency, because they have no variables, everything is a constant.
Lightweight process
Erlang has a spawn function, which can quickly create a process. The process here is not an operating system process, but Erlang's own lightweight process. Erlang is so lightweight that you can imagine. When building a kv database, you can even assign different keys to different processes. Moreover, the representation unit of the process is Pid. As long as you know the Pid of the process, even if the process is on another machine, it can be easily sent to it. The reason is Erlang's [born RPC communication] and [proper port mapping]
Born with RPC communication
ToPid ! Data
ToPid is the id of the receiver process, Data can be any type of Erlang, for example
Pid ! {name, ""}.
That is, any data structure can be directly sent as a message, and it is born with RPC communication. (Although RPC originally means "remote procedure call", it actually helps you serialize the data structure, and the same is true for Erlang's ! operator.)
Process port mapping
The representation of sending messages between nodes in the code is still
ToPid ! Data
That is, when writing code, you don’t have to consider which machine the process is on. Whether it is the Erlang process (the process here is an operating system level process, not an Erlang lightweight process), or the processes of other machines, you don’t have to worry about it. This is because of the existence of epmd.
Epmd is the abbreviation of Erlang Port Mapper Daemon. It is equivalent to the role of dns in Erlang cluster. It provides query services from node names to ports. Epmd is bound to the well-known port 4369.
With epmd, writing distributed programs is as simple as writing stand-alone programs.
Strict modular management
Erlang's module is similar to namespace in C++, but it is more conducive to efficient software engineering management than namespace.
The following code can be seen everywhere in the source code of the Erlang project.
-module(my_app).
-export([start/2, stop/1]).
-module Specifies the module name, and -export Specifies the exported function. No functions that have not been exported cannot be called by the outside world. From a software engineering perspective, this makes the module functions and usage methods clearer. Users only need to care about the functions in -export. In comparison, C++ is particularly irregular in this regard, while Java indicates that the class declaration can be used by the outside world, and also uses export to display functions that declare that the declaration can be used by the outside world.
Behavioral Patterns
-module(ecomet_app).
-behaviour(application).
%% comment: Application callbacks
-export([start/2, stop/1]).
-behavior(application).
The concept of [behavioral pattern] in Erlang/otp is equivalent to the concept of interface in OOP. The above code example means that the behavior pattern that the module (ecomet_app) complies with is (application). The two interface functions that need to be implemented in the Ring behavior pattern are -export([start/2, stop/1]).
Another example is to comply with the supervisor behavior pattern, and an interface function implemented is -export([init/1]).
-module(ecomet_sup).
-behaviour(supervisor).
%% Supervisor callbacks
-export([init/1]).
Supervisor mechanism
Erlang/otp's inherent distributed characteristics are well reflected in the supervision mechanism. When every otp application is started, it is a supervisor and worker. Their relationship is a tree-shaped structure, and each worker's superior will have a supervisor, and each supervisor's superior may also have a supervisor. When the worker exits abnormally, the supervisor will decide whether to restart the worker based on the corresponding parameters. If the restart fails, the supervisor will also exit, and the higher-level supervisor will restart them and other processing after receiving the signal. This supervisor mechanism is very easy to understand. It is actually the try... catch exception handling mechanism in OOP programming. When an exception occurs, throw it up layer by layer until someone restarts.
otp platform
Erlang's most powerful place and the one that makes me feel the most difficult to learn is its otp platform. Various behavior patterns make me feel like when I was studying MFC many years ago. I felt very strong, but I always felt like I was being pressed to death and running on a specific track, feeling tired of being unfree.
Code switching
Hot switching is also called hot upgrade. In most cases, if you need to upgrade the C++/Java program process version, you need to restart the process. Erlang supports hot switching means that code upgrades can be performed when running. The upgrade process does not affect the operation of the process, and the new and old versions can coexist during the transition stage. Is it a bunker? This feature is simply awesome for those services that require high availability of 7x24.
The Erlang process itself can view the status in real time through a "backdoor" console erl, or even directly use the console to modify the configuration, etc., which is very convenient. For most other languages, it is simply a magical existence like black magic.
Typical disadvantages
1. If there are too few documents, there are few answers to search for problems.
Talents are scarce, and recruitment is not easy.
3. The most typical example of dynamic language is that debugging is difficult.
4. The threshold for getting started is high.
Finally, I am just an introductory beginner for Erlang. Because I need to use ejabberd (Erlang's open source project) at work, I learned Erlang and lacked practical experience, so the title of this article is [Erlang First Experience].