I won’t reproduce the image that “learn you some Erlang for great good” uses for a failed update, you will have to visit the blog page to see for yourself.
I can quote the first couple of paragraphs that sets the background for it:
Doing some code hot-loading is one of the simplest things in Erlang. You recompile, make a fully-qualified function call, and then enjoy. Doing it right and safe is much more difficult, though.
There is one very simple challenge that makes code reloading problematic. Let’s use our amazing Erlang-programming brain and have it imagine a gen_server process. This process has a handle_cast/2 function that accepts one kind of argument. I update it to one that takes a different kind of argument, compile it, push it in production. All is fine and dandy, but because we have an application that we don’t want to shut down, we decide to load it on the production VM to make it run.
I suspect that Erlang or something close to it will become the norm in the not too distant future. Mostly because there won’t be an opportunity to “catch up” on all the data streams in the event of re-loading the application. May have buffering in the event of a reader failure but not system wide.