Mods: the article's title is "Getting started with OTP: creating psycho families !".

The title of the HN submission doesn't make much sense, considering the material. I was expecting a discussion of pg2 [0] or similar.

The article's title is apropos, because in Erlang parents often kill their children and vice-versa.

[0] http://erlang.org/doc/man/pg2.html

OTP is an overloaded term, one-time pads, one-time passwords, etc. This one is Open Telecommunications Platform.

Yeah, OTP is an awful name because it's meaningless in the context of programming without reading history from the 1980s. It should really just be called "erlang library frameworks" or something similarly sensible.

This article is largely a copy/paste/reword job from the official erlang docs (http://www.erlang.org/doc/design_principles/gen_server_conce...) too.

I dunno. Something called "Open Telecom Platform" sounds very stodgy and reliable to me. :)

Also known as Outlaw Techno Psychobitch in Erlang community, per [0], as popularized by the creator of the famous "MongoDB is Web Scale". Context [1].

[0] - https://www.youtube.com/watch?v=rRbY3TMUcgQ

[1] - http://www.gar1t.com/blog/otp.html

If you start a service, it's just one process, right? So if it fails, all pending requests will fail, right?

What is the recommended way to contain a failure to a single request?

> If you start a service, it's just one process, right?

If you search for "So we will create a module named ch3 with gen_server behaviour", you'll see the author's server code. His server code makes use of the gen_server behavior.

To answer your questions:

Yes. If the author's server process crashed, all pending requests would be lost. From what I can tell, gen_servers use the Erlang process mailbox to maintain a queue of (among other things) requests to be serviced. If a process dies, its mailbox is destroyed and its contents lost.

If I were concerned about my code's ability to survive a crash of one of its operations, I would either

* Wrap the operation in a try/catch block that only handled all of the error conditions that I was expecting to encounter.

* Execute the operation in a separate, monitored [0] process that sends a message back with the results of the operation. [1]

Each method has its place, but I would find myself using the child process method most of the time. Defensive coding is a really bad code smell in Erlang programs. Swallowing all exceptions is definitely a very defensive thing to do.

[0] Any process in an Erlang system can monitor any other process in the system and get a notification when the monitored process terminates.

[1] You can even tell your supervisor to start the process for you so that it knows about it and can terminate the child if the supervisor is asked to shutdown.

Process spawning is cheap in Erlang so you can spawn a new process for each incoming request. Cowboy does something similar to this. If you don't want to spwan a process for each request then you can have a worker pool (like poolboy) to respond to the requests.