This idea of modeling multiple concurrent things in the world (TCP connections) with multiple concurrent and isolated things in your application is very popular.
That is often the point of Erlang (and now Elixir) and other Actor based frameworks -- starting to think in terms of actors and mailboxes to model your problem.
Now it doesn't have to be about Erlang. You can spawn OS processes, or threads, or processes on different machines and use RabbitQM or 0MQ. Erlang and Elixir gets you the ability to spawn millions of isolated processes. Typically this not possible if using regular OS processes or even threads. It is possible with goroutines in Go for example, but those are not isolated.
If anything just being aware of this mode of developing when today callback-based concurrency and async/deferred/promise is talked about is important. I think it is a better way to model a problem in most cases.
Even outside of web, I find modeling problems the Erlang (and Elixir) way is oftentimes worth thinking about, even if you end up not using it.
Concurrency is notoriously difficult, and so a lot of people 'solve' it by avoiding it. That in turn causes you to think about problems in certain ways. Just being free to treat concurrency as essentially free, and in fact, encouraged, starts a real paradigm shift.
For instance, from something I had to work on, assume you want to write a cron-like.
An 'obvious' way of doing it is to create a priority queue or similar, and keep repeating pop -> execute -> pop -> execute.
Then requirements change, suddenly each task you fire has multiple steps to it. So you pop -> execute -> push -> pop -> execute -> push.
Then you realize these things take -time- to execute, and that is causing some times to be missed, so you pop -> grab thread from pool -> execute in thread (thread pushes) -> pop. Crap, there's a race condition; is the thread going to push the next thing this item needs in time for the pop? Well, maybe change it, the thread handles all the remaining action items for that job? But what if it's long lived, how does my thread pool look, will we exhaust the pool? Suddenly you have complexity.
In Erlang, you just start by defining each scheduled job as a process whose job is to figure out when next to execute the next step for -that job-. You don't need to know about the others. Done.
Totally agree. Actors and mailboxes are a great way to think about these kinds of problems, and Erlang/Elixir does such a good job at it. Now if I could only get the EventMachine side of this app to work anywhere near as well.
[+] [-] rdtsc|12 years ago|reply
That is often the point of Erlang (and now Elixir) and other Actor based frameworks -- starting to think in terms of actors and mailboxes to model your problem.
Now it doesn't have to be about Erlang. You can spawn OS processes, or threads, or processes on different machines and use RabbitQM or 0MQ. Erlang and Elixir gets you the ability to spawn millions of isolated processes. Typically this not possible if using regular OS processes or even threads. It is possible with goroutines in Go for example, but those are not isolated.
If anything just being aware of this mode of developing when today callback-based concurrency and async/deferred/promise is talked about is important. I think it is a better way to model a problem in most cases.
[+] [-] lostcolony|12 years ago|reply
Concurrency is notoriously difficult, and so a lot of people 'solve' it by avoiding it. That in turn causes you to think about problems in certain ways. Just being free to treat concurrency as essentially free, and in fact, encouraged, starts a real paradigm shift.
For instance, from something I had to work on, assume you want to write a cron-like.
An 'obvious' way of doing it is to create a priority queue or similar, and keep repeating pop -> execute -> pop -> execute.
Then requirements change, suddenly each task you fire has multiple steps to it. So you pop -> execute -> push -> pop -> execute -> push.
Then you realize these things take -time- to execute, and that is causing some times to be missed, so you pop -> grab thread from pool -> execute in thread (thread pushes) -> pop. Crap, there's a race condition; is the thread going to push the next thing this item needs in time for the pop? Well, maybe change it, the thread handles all the remaining action items for that job? But what if it's long lived, how does my thread pool look, will we exhaust the pool? Suddenly you have complexity.
In Erlang, you just start by defining each scheduled job as a process whose job is to figure out when next to execute the next step for -that job-. You don't need to know about the others. Done.
[+] [-] jeetkundoug|12 years ago|reply
[+] [-] ksec|12 years ago|reply