Myths and Legends vs ErLang

Recently, I often come across myths about the Erlang programming language and, at first, it was funny, but when we began to make management conclusions based on these myths, it was not a dramatic laugh.

So, what is immediately remembered when it comes to Erlang? Usually they remember that this is a “ parallel programming language ” and, secondly, “ it has a slow mathematics ”, and “it’s better not to use floating-point numbers because it’s a tractor ”.

With the “ floating point ” there were in fact difficulties, more precisely, the speed of work was not pleasing, only now since ten years have passed. More precisely, from the time when it was true.

When they talk about slow math, I immediately want to ask: “ compared to what ”? Agree that a person is inferior in computational speed even to a calculator, but because of this we do not beat our heads against the walls with shouts of “ woe, woe to us ”. In general, if you need fast calculations, CUDA is in your hands ...
')
- Stop! - the attentive reader will say. - But I clearly remember that this Erlang is used in clusters which consider something there.

And, again, right. The key word here is the cluster . Erlang was created for other purposes for which it is truly indispensable and this is one of them.

Imagine that there is a stream of data that needs to be processed and, preferably, in near real-time mode. To put it mildly, the stream is large and you don’t have to crank it all on one computer, which means that you need to deploy a farm . But, unfortunately, the standard distributions for the organization of " farms " are not suitable for you. And non-standard ones are not available ... blockade there, financial difficulties or something else, it does not matter.

And here you write the number crusher in C or CUDA, make an image and deploy the required number of machines (Node). Well, then, Erlang, by the sweat of his face, is committed to ensuring consistent and trouble-free operation.

And here we come to the thesis that Erlang is a “ parallel programming language ”.
Here it is worth noting immediately that the phrase itself is not built correctly. Because there are no parallel and perpendicular languages. Okay, okay, I will not find fault with the words.

So, it is believed that Erlang was developed as a language for providing parallel computing, but this is not the case, more precisely, it is not at all.
The Erlang programming language was developed not for entertainment, but as a completely industrial language. And, the main feature of the language was ... reliability .

Yes, since this language is functional, then, in principle, it can be proved that a certain program is “ reliable ”. That is, her behavior is predictable and provable. And now let us recall that the language was developed for telecom, where reliability is the cornerstone.

- What about parallelism? - the reader will be upset.

And parallelism is a side effect of the chosen language architecture. A kind of bonus. After all, in fact, Erlang does not parallelize anything by itself, it only provides the programmer with the necessary set of features for conveniently writing such programs. Let me remind you that during the creation of the language, and this is the end of the 80s, with multi-core and multiprocessor computers, it was impossible to say that it was thick. As they say, this product was purely piece.

But, parallelism, or rather, the work of the application on several nodes is also an element of increasing reliability. More precisely, this is to ensure the reliability of not the code, but the reliability of the hardware.

Another bonus, it turned out already because of parallelism. Since there are no side effects and the code is distributed parallelized, you can use the garbage collector with a clear conscience, since it will not hang the entire application. Thus, we get protection from the most common errors associated with memory leaks. But this is also an element of reliability.

It remains to be remembered that the application can be updated without stopping it completely and the basic principle of the language should be clear - “ reliability ” and “ predictability ”.

Behind this, allow me to bow out ... and do not make management decisions based on myths and conjectures.