

Elixir and the Internet of Things – What's in a Process? - jambo
http://www.neo.com/2014/01/30/elixir-and-the-internet-of-things-part-2-what-s-in-a-process

======
rdtsc
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.

~~~
lostcolony
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.

------
ksec
So Elixir is now production ready?

