Erlang: An introduction to gen_fsm by creating an ATM (Part 2) | Hacker News Reader

Erlang: An introduction to gen_fsm by creating an ATM (Part 2)

spawnlink.com

26 pointsmitchellh8 comments

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?

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.

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

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.

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

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)

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

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

Reply on news.ycombinator.com