4 ms·

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 doub

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.

gcr 11y ago
How is that different than just throwing an uncaught exception? Most web toolkits will catch that, log it, and 500 the client for you.
- statictype 11y ago
  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.
mason55 11y ago
> 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.
felixgallo 11y ago
Joe Armstrong is one of the original authors of Erlang. He's using the erlang nomenclature for servers and processes.
vonkow 11y ago
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".
greenleafjacob 11y ago
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
tbrooks 11y ago
OS processes !== BEAM process He's referencing processes on the Erlang virtual machine, not OS processes. A BEAM process is much lighter weight.
rdtsc 11y ago
> 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.

gcr 11y ago

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

statictype 11y ago
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.

mason55 11y ago

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

felixgallo 11y ago

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

vonkow 11y ago

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

greenleafjacob 11y ago

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

tbrooks 11y ago

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

rdtsc 11y ago

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