Hacker News Reader

Comment by jondubois | Hacker News Reader

You don't need to "crash the server" in response to an error from a single user - It is sufficient to just close the connection and destroy the session.

I doubt that erlang spawns millions of OS processes because that would be extremely inefficient due to CPU context switching. So in reality, all erlang is doing behind the scenes is closing the connection and destroying the session... It's not actually crashing and restarting any processes... You can easily implement this behavior with pretty much any modern server engine such as Node.js and tornado.

View on HN

Yes, you can (mostly) implement this behaviour in pretty much any modern server framework or language. The point is, you get this behaviour for free as a core part of the language. I write a lot more javascript than erlang these days and I really miss being able to just say, "let it fail".

Consider uncaught exceptions. You basically have two options: catch and ignore, or restart the entire application, usually with something like monit or upstart. Both aren't great. Erlang/OTP brings true fault tolerance in a number of ways [1]. Think of it like having a monit baked into the language as a first class primitive.

[1] restricting global shared memory, enforcing fault isolation through the process model, and supervisors

> I doubt that erlang spawns millions of OS processes because that would be extremely inefficient due to CPU context switching.

You are correct, Erlang uses something akin to "green processes" where it manages its own threads but they do not share anything in the way that normal threads would.

Joe Armstrong is one of the original authors of Erlang. He's using the erlang nomenclature for servers and processes.

> sufficient to just close the connection and destroy the session.

Unless that connection managed to write over some memory already. Then you can't just close the connection. You have to restart the whole server OS process.

> I doubt that erlang spawns millions of OS processes because that would be extremely inefficient due to CPU context switching

Erlang does spawn millions of processes. You can try it yourself in a few lines of code. They are not OS processes though. Although they are similar in that OS processes and Erlang ones don't share memory with their peers -- a very useful property indeed.

So Erlang in a way can have it cake and eat it took. It gets the benefit of OS processes but at a much lower cost.

OS processes !== BEAM process

He's referencing processes on the Erlang virtual machine, not OS processes. A BEAM process is much lighter weight.

How is that different than just throwing an uncaught exception? Most web toolkits will catch that, log it, and 500 the client for you.

Your web service is stateless - for those cases it's fine. However with this model, you are offloading all your state to another layer - likely the database layer.

With Erlang (or rather, the Actor model), you can build state-full pieces of code that are also resilient to crashes that cascade across the entire system, by having a standard pattern of restarting individual actors from a known clean state through a clean supervisor hierarchy.

Reply on news.ycombinator.com