

Erlang: An introduction to gen_fsm by creating an ATM (Part 2) - mitchellh
http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/

======
truebosko
I think this article and the one before it is great, but I have a hard time
understanding real world usage with Erlang.

I know Facebook chat and other high-scale applications were done with Erlang
but apart from that, how is it useful over say Python for more simpler
applications and systems?

~~~
mitchellh
Erlang is useful for writing concurrent, high availability systems. If you're
writing a simple script to grep a directory and delete a few files or
something, a scripting language like Python is fine. If you're writing a basic
blog even, I'd say a scripting language like Python is the way to go.

But if you're writing a service like a database where there must be a lot of
concurrent connections, Erlang has the feel of a high-level scripting
languages, while being a compiled byte-code language.

Also, since Erlang processes are so lightweight and can run across multiple
cores, it scales nicely with new CPUs coming out. So, usually without changing
any of your code, as 4, 8, 16 core CPUs come out, your Erlang script should
theoretically run 4x, 8x, and 16x faster, respectively.

~~~
hassy
> So, usually without changing any of your code, as 4, 8, 16 core CPUs come
> out, your Erlang script should theoretically run 4x, 8x, and 16x faster,
> respectively.

You might want to read this: <http://en.wikipedia.org/wiki/Amdahl's_law>

The program would have to be 100% CPU-bound _and_ the problem would have to be
inherently parallelizable to see Nx speedup with N times as much CPU resource.

The kind of code that benefits most from more cores is the kind of code you
probably should _not_ write in Erlang actually.

~~~
mitchellh
I understand this but its purely theoretical. Of course you won't see those
kind of increases, but you would see increases.

Why wouldn't you want to write something that benefits from more cores in
Erlang? Erlang is written for concurrent processes and in the face of more
cores (with SMP enabled) it will spread them across the cores for you.

~~~
hassy
Well, CPU-intensive code is likely to do some sort of number crunching. Erlang
was not designed with such tasks in mind and it has no supporting libraries.
C++ or Fortran would be a better fit, or even Python with Numpy.

Erlang (and by this I mean the whole runtime, not just the language) was
designed for fault-tolerance; that's where all the features such as ease of
distribution, shared-nothing architecture, built-in lightweight concurrency
etc stem from.

Right tool for the right job and all that...

~~~
mitchellh
This is true, its not a processing powerhouse but for concurrent applications,
Erlang is a clear choice. You don't have to do anything special to gain
multiple core support.

Even with cpu-intensive number crunching, I would rather write an erlang
linked-in driver in C and use Erlang's concurrency model to run the code
rather than write multi-core enabled map/reduce type things in C. (ewwww)

~~~
hassy
> for concurrent applications, Erlang is a clear choice.

No it's not. Not necessarily.

Concurrency is a means to an end, not a goal. Erlang is great for problems
which lend themselves well to modeling with a large number of communicating
processes. A parallelizable number-crunching task is not such a problem.

By the way, just to be clear, by "number crunching" I mean something like
rendering CGI.

> Even with cpu-intensive number crunching, I would rather write an erlang
> linked-in driver in C and use Erlang's concurrency model to run the code
> rather than write multi-core enabled map/reduce type things in C. (ewwww)

Concurrency in the Erlang VM will not magically translate into concurrency in
your driver. By default only one emulator thread at a time is allowed to
execute code in the driver. You can override that, and then probably have to
deal with a lot of synchronization and locking issues in the driver. Why
bother?

Most number-crunching software out there is written in C, C++ or Fortran --
probably for a good reason (I have no experience in this area). There are many
libraries, frameworks and tools to help you with parallelizing things (e.g.
OpenMP). Erlang is simply not a good choice for this sort of software.

Too many people focus on how Erlang is well-suited for multicore systems.
_Forget multicore._ It's neat, but the real awesomeness of Erlang is in
distribution and fault-tolerance, not parallelization.

~~~
mitchellh
You're right in many ways. I think I'm thinking too generally at the moment
and not about specific tasks :)

Erlang has its strong points just as every other language. =]

