Why Erlang
Original article: smyck.net/2012/04/22/why-erlang The
chances that you read this article on a multicore device are growing every day, which is why everyone is constantly talking about concurrency. Concurrency for our web applications and backend APIs is when the htop output looks something like the picture:
I was at a great Ruby conference recently and three or four talks were about concurrency. The Ruby community is fairly open and there are a lot of possibilities discussed: use threads, use different Ruby runtimes to bypass the GIL , use more processors, use an actor model through libraries like Celluloid, or even useAkka via JRuby.
While the actor model seems to be well suited for creating networked parallel applications, which often suffers 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 tuned in order to achieve normal operation and not necessarily the result gives the best performance. This is one of many reasons why Erlang would be a much better choice, but first, let's take a little time with the actor model to understand why this works so well.
Here is a nice quote from wikipedia, for a superficial understanding:
Despite some similarities between actors and objects, such as: modularity, encapsulation and the ability to send messages; actors have a unique feature - they can do their job at the same time.
In other words, sending messages to share state with other actors works in parallel, allowing asynchronous interaction, which means that the sender does not have to wait for a response from the recipient.
Another big difference from the OOP world is that the actor model does not have a global state and therefore do not share a common memory between the actors. In languages such as Java, Ruby, and Python, global state is always used and threads have access to shared memory. This fact often becomes a problem in the form of locks or state races.and perhaps the greatest inconvenience
In the actor model, each actor has its own internal state, which is distributed only through messages. In this way, the actor acts as a serializer to access its state, thereby effectively blocking and blocking race conditions.
It should also be noted that the actor model is very well suited for functional programming languages with the concept of immutable data.
There is a lot to read about actors, but I would point out the most important thing to know. In general, an actor model makes developing parallel applications much easier and faster.
First, I'd like to say that for many years I was 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 comes 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 came into my view a long time ago, but from the height of my ivory tower and ruby roof it took a lot of attempts to understand that it is worth a try. 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 admit that I was shocked by the syntax of the language and this stopped me
from the desire to try this language. I think this was a big mistake that motivated me to write this article, to tell you that you should try Erlang as quickly as possible.
First, let me describe Erlang in one line:
“Erlang is a functional language implemented on the model of actors for parallel applications.”
This language was developed by Ericsson for its telecommunication switches and the goal was to create a language that would allow developing fault-tolerant and parallel systems with high availability.
You can read about everything on wikipedia or a great 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 this by telling the story of the application of Erlang in Wooga .
Wooga makes social games with millions of active players per day. Games constantly tell servers to change and maintain the state of game participants. Some of our games were 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 largest game, in terms of the number of users, with complex internal logic, runs on servers 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 must note that although the number of servers is kept within reasonable limits at the time of peak loads, the figure, of course, is 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 on Erlang ( Knut ) and together they implemented the logic. Now this game has about 50% of the players from the rest of the games and the number of servers needed to service it is 1! ..
The game is served by two or three servers for some redundancy, but it can work perfectly perfectly on one as well. 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 lack of Erlang, it helped to achieve such a performance increase and contributed to the implementation of logic, it was really easier to achieve the goal with the help of the actor model.
In another language, they created a web server to store the status of players, which means that each player who is screaming at the moment is served by a separate actor inside Erlang VM. The player, starting the game, creates an actor with his state. Subsequent requests, while he is playing, go directly to the actor with whom he is associated. Accordingly, while the state of the game is stored in memory, any calls to the database are excluded, requests are processed and respond very quickly.
If an actor falls, the remaining actors remain “alive” since there is no general / global state. When a player stops the game, the actor saves the player’s state in permanent storage and the garbage collector (GC) will delete it from memory. At the same time, as we recall, the data in Erlang does not change, which allows you to return the player’s state until the changes have occurred and something went wrong.
It is truly amazing and I can tell you a lot more. Fortunately, Knut and Paolo spoke at several conferences about our experience and put their slides in the public domain. 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 whole company with the Erlang virus, we made a new game on Erlang and several additional services. I can confirm that the more you learn Erlang, the more you understand how to do it right. This makes me a little sorry for those who at Ruby conferences struggled with various libraries so that you can easily develop parallel applications, which provides Erlang in one package. A package that has been used for over 20 years.
The hard part in learning a new language is finding a small project and taking part in it. Studying just by reading books is always slow, and when you start writing code, most of what you read is forgotten. Also, the strange syntax (I don’t find it strange now) was an insurmountable obstacle for me to start using Erlang in a real project. Therefore, I recommend choosing a small project and "playing around" with Erlang. I think you will not regret it.
I hope to write an article in the near future as I studied Erlang and put it out. In the meantime, you yourself can start learning by visiting learnyousomeerlang.com . Trust me - this is a better choice than any Erlang books currently available.
PS: Thanks Elise Huardfor proofreading! If you have comments, images of ivory towers with a ruby roof to make the article more colorful or any wishes, send me them immediately!
chances that you read this article on a multicore device are growing every day, which is why everyone is constantly talking about concurrency. Concurrency for our web applications and backend APIs is when the htop output looks something like the picture:
I was at a great Ruby conference recently and three or four talks were about concurrency. The Ruby community is fairly open and there are a lot of possibilities discussed: use threads, use different Ruby runtimes to bypass the GIL , use more processors, use an actor model through libraries like Celluloid, or even useAkka via JRuby.
While the actor model seems to be well suited for creating networked parallel applications, which often suffers 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 tuned in order to achieve normal operation and not necessarily the result gives the best performance. This is one of many reasons why Erlang would be a much better choice, but first, let's take a little time with the actor model to understand why this works so well.
Actors Model
Here is a nice quote from wikipedia, for a superficial understanding:
“The model of actors proceeds from such a philosophy that everything around is an actor. 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, as a rule, are executed sequentially, while in the actor model the calculations are essentially the same in time. ”
Despite some similarities between actors and objects, such as: modularity, encapsulation and the ability to send messages; actors have a unique feature - they can do their job at the same time.
In other words, sending messages to share state with other actors works in parallel, allowing asynchronous interaction, which means that the sender does not have to wait for a response from the recipient.
Another big difference from the OOP world is that the actor model does not have a global state and therefore do not share a common memory between the actors. In languages such as Java, Ruby, and Python, global state is always used and threads have access to shared memory. This fact often becomes a problem in the form of locks or state races.and perhaps the greatest inconvenience
In the actor model, each actor has its own internal state, which is distributed only through messages. In this way, the actor acts as a serializer to access its state, thereby effectively blocking and blocking race conditions.
It should also be noted that the actor model is very well suited for functional programming languages with the concept of immutable data.
There is a lot to read about actors, but I would point out the most important thing to know. In general, an actor model makes developing parallel applications much easier and faster.
OK, what about Erlang?
First, I'd like to say that for many years I was 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 comes 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 came into my view a long time ago, but from the height of my ivory tower and ruby roof it took a lot of attempts to understand that it is worth a try. 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 admit that I was shocked by the syntax of the language and this stopped me
from the desire to try this language. I think this was a big mistake that motivated me to write this article, to tell you that you should try Erlang as quickly as possible.
First, let me describe Erlang in one line:
“Erlang is a functional language implemented on the model of actors for parallel applications.”
This language was developed by Ericsson for its telecommunication switches and the goal was to create a language that would allow developing fault-tolerant and parallel systems with high availability.
You can read about everything on wikipedia or a great site: learnyousomeerlang.com - These guys did an excellent job describing the language.
Case Study 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 this by telling the story of the application of Erlang in Wooga .
Wooga makes social games with millions of active players per day. Games constantly tell servers to change and maintain the state of game participants. Some of our games were 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 largest game, in terms of the number of users, with complex internal logic, runs on servers 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 must note that although the number of servers is kept within reasonable limits at the time of peak loads, the figure, of course, is 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 on Erlang ( Knut ) and together they implemented the logic. Now this game has about 50% of the players from the rest of the games and the number of servers needed to service it is 1! ..
The game is served by two or three servers for some redundancy, but it can work perfectly perfectly on one as well. 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 lack of Erlang, it helped to achieve such a performance increase and contributed to the implementation of logic, it was really easier to achieve the goal with the help of the actor model.
In another language, they created a web server to store the status of players, which means that each player who is screaming at the moment is served by a separate actor inside Erlang VM. The player, starting the game, creates an actor with his state. Subsequent requests, while he is playing, go directly to the actor with whom he is associated. Accordingly, while the state of the game is stored in memory, any calls to the database are excluded, requests are processed and respond very quickly.
If an actor falls, the remaining actors remain “alive” since there is no general / global state. When a player stops the game, the actor saves the player’s state in permanent storage and the garbage collector (GC) will delete it from memory. At the same time, as we recall, the data in Erlang does not change, which allows you to return the player’s state until the changes have occurred and something went wrong.
It is truly amazing and I can tell you a lot more. Fortunately, Knut and Paolo spoke at several conferences about our experience and put their slides in the public domain. 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 whole company with the Erlang virus, we made a new game on Erlang and several additional services. I can confirm that the more you learn Erlang, the more you understand how to do it right. This makes me a little sorry for those who at Ruby conferences struggled with various libraries so that you can easily develop parallel applications, which provides Erlang in one package. A package that has been used for over 20 years.
The hard part in learning a new language is finding a small project and taking part in it. Studying just by reading books is always slow, and when you start writing code, most of what you read is forgotten. Also, the strange syntax (I don’t find it strange now) was an insurmountable obstacle for me to start using Erlang in a real project. Therefore, I recommend choosing a small project and "playing around" with Erlang. I think you will not regret it.
I hope to write an article in the near future as I studied Erlang and put it out. In the meantime, you yourself can start learning by visiting learnyousomeerlang.com . Trust me - this is a better choice than any Erlang books currently available.
PS: Thanks Elise Huardfor proofreading! If you have comments, images of ivory towers with a ruby roof to make the article more colorful or any wishes, send me them immediately!