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 draw managerial conclusions on the basis of these myths, it became sharply no laughing matter.

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

    In fact, there were difficulties with the " floating point ", more precisely, the speed of work was not pleasing, only ten years have passed since then. More precisely, from the time when this was true.

    When people talk about slow math, I immediately want to ask: “compared with what ? You must admit that a person is even inferior in terms of speed to a calculator, but because of this, we don’t bang our heads against the walls shouting “ about grief, woe to us ”. In general, if you need fast computing, CUDA is in your hands ...

    - Stop! - the attentive reader will say. “But I clearly remember that this Erlang of yours is used in clusters that 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 certain stream of data that needs to be processed and, preferably, in a mode close to real time. The flow is, to put it mildly, large and you can’t do it all on one computer, which means that you need to deploy a “ farm ”. But, as luck would have it, standard distributions for organizing " farms " do not suit you. And non-standard ones are not available ... the blockade there, financial difficulties or something else, doesn’t 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 in the sweat of the face is committed to ensuring a 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 built incorrectly. For parallel and even more perpendicular languages ​​do not exist. Okay, okay, I won’t find fault with the words.

    So, it is believed that Erlang was developed as a language for providing parallel computing, but this is not so, or rather 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, in principle, it can be proved that a certain program is “ reliable ”. That is, her behavior is predictable and provable. Now remember that the language was developed for telecom, where reliability is the cornerstone.

    - But what about parallelism? - the reader will ask in frustration.

    And parallelism is a side effect of the chosen language architecture. A kind of bonus. Indeed, in fact, Erlang, in itself, does not parallelize anything, it only provides the programmer with the necessary set of features for convenient writing of such programs. Let me remind you that at the time of the creation of the language, and this is the end of the 80s, with multi-core and multi-processor computers it was not that dense. As the saying goes, this product was purely piece.

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

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

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

    For sim, allow me to take my leave ... and do not make managerial decisions based on myths and conjectures.

    Also popular now: