Why Erlang?
Original article: smyck.net/2012/04/22/why-erlang
The chances that you are reading this article on a device with a multi-core processor are growing every day, which is why everyone constantly talks about concurrency. Parallelism for our web applications and backend APIs is when htop output looks something like the picture:
')
I was recently at a great Ruby conference and three or four reports were about concurrency. The Ruby community is quite open and discussed quite a lot of possibilities: use threads, use different Ruby runtimes to get around GIL , use more processors, use actor model through libraries like Celluloid, or even use Akka through JRuby.
While the model of actors seems to be well suited for creating network parallel applications that often suffer from problems if the runtime environment on which the application is implemented does not have native support. There are implementations for Ruby, Python, and Java, but they all need to be tailored to achieve normal operation and not necessarily the result gives the best performance. This is one of the many reasons why Erlang would be a much better choice, but first, let's take a little time to model the actors to understand why this works so well.
Here is a good quote from wikipedia, for superficial understanding:
Despite some similarities between actor and objects, such as: modularity, encapsulation and the ability to send messages; actors have a unique feature - they can do their work at the same time.
In other words, sending messages to share the state with other actors works in parallel allowing for asynchronous interaction, which means that the sender does not have to wait for a response from the receiver.
Another big difference from the PLO world is that the model of actors does not have a global state and therefore does not share the common memory between actors. In languages ​​such as: Java, Ruby and Python, the global state is always used and threads have access to shared memory. This circumstance often becomes a problem in the form of locks or races of states and is possibly the greatest inconvenience.
In the model of actors, each actor has its own internal state, which is distributed only through messages. Thus, the actor acts as a serializer to access its state, thereby effectively avoiding blocking and race conditions.
It should also be noted that the model of actors is very well suited for functional programming languages ​​with the concept of immutable data (Immutable Data).
There is a lot that you can read about the actors, but I would point out the most important thing you need to know. In general, the actor model makes it possible to develop parallel applications much easier and faster.
First, I would like to say that for many years I have been a passionate Ruby developer. I really like this language and its community. But from time to time I felt that I was overcoming invisible walls when it came to network applications, web applications, web servers, proxies, etc. That is, all those applications that process multiple requests and / or perform non-trivial tasks.
Erlang was in my field for a long time, but from the height of my ivory tower and ruby ​​roof it took many attempts to realize that it was worth trying. Conceptually, this is of great importance to me, and I am sure that most people who read about Erlang will agree with me. I must confess that I was shocked by the syntax of the language and it stopped me
from wanting to try this language. I think this was a big mistake, which motivated me to write this article, to tell you that you should try Erlang as soon as possible.
First let me give Erlang a one-line description:
“Erlang is a functional language implemented on actor models for parallel applications.”
This language was developed by Ericsson for its telecommunications switches and the goal was to create a language that would allow the development of fault-tolerant and parallel systems with high availability.
You can read about everything on wikipedia or the magnificent site: learnyousomeerlang.com - These guys did an excellent job describing the language.
This article is a kind of push, I want to encourage you to try Erlang and I will try to do it telling the story of Erlang's use in Wooga .
Wooga makes social games with millions of active players per day. Games constantly tell servers to change and retain the status of game participants. Some of our games have been developed in Ruby and they work well. Ruby, as I said, is a really good language and although not the fastest, it can be quite productive if you know what you are doing.
Our biggest game, by the number of users, with complex internal logic, runs on servers ranging from 80 to 200. They process about 5000-7000 requests every second and almost all requests change the player’s state in the game itself. I should note, although the number of servers is kept within reasonable limits at the time of peak loads, but the figure is, of course, not the most impressive.
When it came time to create a new game with similar logic and complexity, this time my colleague Paolo decided to choose Erlang, he thought it would be the right choice. We hired an experienced developer at Erlang ( Knut ) and together they implemented the logic. Now this game has about 50% of players from other games and the number of servers required to serve it is 1! ..
The game is served by two or three servers for some redundancy, but it can perfectly work on one. Even if the game really needs four servers, it will still be much more efficient and productive than other games.
Of course, they already knew about all the mistakes made in previous games and this is not only the absence of Erlang, it helped to achieve such an increase in performance and contributed to the implementation of logic, it was really easier to achieve this goal using the model of actors.
Speaking in a different language, they created a web server to store the state of the players, which means that each player who plays the moment is served by a separate actor inside the Erlang VM. A player, starting a game, generates an actor with his condition. Subsequent requests, while he plays, go directly to the actor with whom he is associated. Accordingly, while the state of the game is stored in memory, this excludes any access to the database, requests are processed and respond very quickly.
If the actor falls, the other actors remain “alive” as there is no common / global state. When a player stops playing, the actor stores the player’s state in permanent storage and the garbage collector (GC) removes it from memory. At the same time, as we remember, the data in Erlang does not change, which allows the player to return the status of the player until there are any changes and something goes wrong.
This is really amazing and I can tell a lot more. Fortunately, Knut and Paolo spoke at several conferences about our experience and laid out their slides in open access. You can view them at the links:
* www.slideshare.net/wooga/erlang-factory-sanfran
* www.slideshare.net/hungryblank/getting-real-with-erlang
After Paolo and Knut infected the entire company with the Erlang virus, we made a new game on Erlang and several additional services. I can confirm that the more you study Erlang, the more you understand how to do it right. It makes me feel a little sorry for those who, at Ruby conferences, struggled with different libraries so that parallel applications could be easily developed, which Erlang provides in one package. A package that has been used for over 20 years.
The difficult part in learning a new language is to find a small project and take part in it. Studying, just reading books, always slowly and when you start writing code, most of what you read is forgotten. Also, the strange syntax (now I don’t find it strange) was an insurmountable barrier for me to start using Erlang in a real project. For this, I recommend choosing a small project and “play around” with Erlang. I think you will not regret.
I hope to write an article in the near future as I studied Erlang and post it. In the meantime, you yourself can start exploring by visiting learnyousomeerlang.com . Trust me - this is a better choice than any books on Erlang currently available.
PS: Thank you Elise Huard for proofreading! If you have comments, images of ivory towers with a ruby ​​roof, to make the article more colorful or any wishes, send them to me immediately!
The chances that you are reading this article on a device with a multi-core processor are growing every day, which is why everyone constantly talks about concurrency. Parallelism for our web applications and backend APIs is when htop output looks something like the picture:
')
I was recently at a great Ruby conference and three or four reports were about concurrency. The Ruby community is quite open and discussed quite a lot of possibilities: use threads, use different Ruby runtimes to get around GIL , use more processors, use actor model through libraries like Celluloid, or even use Akka through JRuby.
While the model of actors seems to be well suited for creating network parallel applications that often suffer from problems if the runtime environment on which the application is implemented does not have native support. There are implementations for Ruby, Python, and Java, but they all need to be tailored to achieve normal operation and not necessarily the result gives the best performance. This is one of the many reasons why Erlang would be a much better choice, but first, let's take a little time to model the actors to understand why this works so well.
Actor Model
Here is a good quote from wikipedia, for superficial understanding:
“The model of actors proceeds from such a philosophy that everything around is actors. This is similar to the philosophy of object-oriented programming, where everything around is some objects, but differs in that in object-oriented programming, programs are usually executed sequentially, while in the model of actors, the calculations are essentially the same. ”
Despite some similarities between actor and objects, such as: modularity, encapsulation and the ability to send messages; actors have a unique feature - they can do their work at the same time.
In other words, sending messages to share the state with other actors works in parallel allowing for asynchronous interaction, which means that the sender does not have to wait for a response from the receiver.
Another big difference from the PLO world is that the model of actors does not have a global state and therefore does not share the common memory between actors. In languages ​​such as: Java, Ruby and Python, the global state is always used and threads have access to shared memory. This circumstance often becomes a problem in the form of locks or races of states and is possibly the greatest inconvenience.
In the model of actors, each actor has its own internal state, which is distributed only through messages. Thus, the actor acts as a serializer to access its state, thereby effectively avoiding blocking and race conditions.
It should also be noted that the model of actors is very well suited for functional programming languages ​​with the concept of immutable data (Immutable Data).
There is a lot that you can read about the actors, but I would point out the most important thing you need to know. In general, the actor model makes it possible to develop parallel applications much easier and faster.
Well, what about Erlang?
First, I would like to say that for many years I have been a passionate Ruby developer. I really like this language and its community. But from time to time I felt that I was overcoming invisible walls when it came to network applications, web applications, web servers, proxies, etc. That is, all those applications that process multiple requests and / or perform non-trivial tasks.
Erlang was in my field for a long time, but from the height of my ivory tower and ruby ​​roof it took many attempts to realize that it was worth trying. Conceptually, this is of great importance to me, and I am sure that most people who read about Erlang will agree with me. I must confess that I was shocked by the syntax of the language and it stopped me
from wanting to try this language. I think this was a big mistake, which motivated me to write this article, to tell you that you should try Erlang as soon as possible.
First let me give Erlang a one-line description:
“Erlang is a functional language implemented on actor models for parallel applications.”
This language was developed by Ericsson for its telecommunications switches and the goal was to create a language that would allow the development of fault-tolerant and parallel systems with high availability.
You can read about everything on wikipedia or the magnificent site: learnyousomeerlang.com - These guys did an excellent job describing the language.
A practical example of using Erlang in Wooga
This article is a kind of push, I want to encourage you to try Erlang and I will try to do it telling the story of Erlang's use in Wooga .
Wooga makes social games with millions of active players per day. Games constantly tell servers to change and retain the status of game participants. Some of our games have been developed in Ruby and they work well. Ruby, as I said, is a really good language and although not the fastest, it can be quite productive if you know what you are doing.
Our biggest game, by the number of users, with complex internal logic, runs on servers ranging from 80 to 200. They process about 5000-7000 requests every second and almost all requests change the player’s state in the game itself. I should note, although the number of servers is kept within reasonable limits at the time of peak loads, but the figure is, of course, not the most impressive.
When it came time to create a new game with similar logic and complexity, this time my colleague Paolo decided to choose Erlang, he thought it would be the right choice. We hired an experienced developer at Erlang ( Knut ) and together they implemented the logic. Now this game has about 50% of players from other games and the number of servers required to serve it is 1! ..
The game is served by two or three servers for some redundancy, but it can perfectly work on one. Even if the game really needs four servers, it will still be much more efficient and productive than other games.
Of course, they already knew about all the mistakes made in previous games and this is not only the absence of Erlang, it helped to achieve such an increase in performance and contributed to the implementation of logic, it was really easier to achieve this goal using the model of actors.
Speaking in a different language, they created a web server to store the state of the players, which means that each player who plays the moment is served by a separate actor inside the Erlang VM. A player, starting a game, generates an actor with his condition. Subsequent requests, while he plays, go directly to the actor with whom he is associated. Accordingly, while the state of the game is stored in memory, this excludes any access to the database, requests are processed and respond very quickly.
If the actor falls, the other actors remain “alive” as there is no common / global state. When a player stops playing, the actor stores the player’s state in permanent storage and the garbage collector (GC) removes it from memory. At the same time, as we remember, the data in Erlang does not change, which allows the player to return the status of the player until there are any changes and something goes wrong.
This is really amazing and I can tell a lot more. Fortunately, Knut and Paolo spoke at several conferences about our experience and laid out their slides in open access. You can view them at the links:
* www.slideshare.net/wooga/erlang-factory-sanfran
* www.slideshare.net/hungryblank/getting-real-with-erlang
More Erlang in Wooga
After Paolo and Knut infected the entire company with the Erlang virus, we made a new game on Erlang and several additional services. I can confirm that the more you study Erlang, the more you understand how to do it right. It makes me feel a little sorry for those who, at Ruby conferences, struggled with different libraries so that parallel applications could be easily developed, which Erlang provides in one package. A package that has been used for over 20 years.
The difficult part in learning a new language is to find a small project and take part in it. Studying, just reading books, always slowly and when you start writing code, most of what you read is forgotten. Also, the strange syntax (now I don’t find it strange) was an insurmountable barrier for me to start using Erlang in a real project. For this, I recommend choosing a small project and “play around” with Erlang. I think you will not regret.
I hope to write an article in the near future as I studied Erlang and post it. In the meantime, you yourself can start exploring by visiting learnyousomeerlang.com . Trust me - this is a better choice than any books on Erlang currently available.
PS: Thank you Elise Huard for proofreading! If you have comments, images of ivory towers with a ruby ​​roof, to make the article more colorful or any wishes, send them to me immediately!
Source: https://habr.com/ru/post/179053/
All Articles