Item — HN Reader

"we advise our clients to kill & quickly restart when their applications enter an unexpected-error state"

Wait, what?

Shouldn't your thing actually work. How unprofessional is it to advise clients to kill and restart things instead of fixing the issue that caused this to be needed?

Wow!

4 comments

Our codebase (not Node-based) is over a million lines of code. It's going to crash at some point. Probably even a lot. Thus, it has been built so that it can be restarted without too much issue or ceremony.

This is doubly helpful because, as a side-effect, you can spin up or down new instances pretty easily because that operation is highly similar to crash recovery via restarting.

That was part of Zed Shaw's "Rails is a Ghetto" rant years ago, that the best Rails developer was proud that his application only crashed like 80 times per minute.

The argument here is that when things go sour you can restore a running process more quickly. Of course things should actually work and issues should be fixed, nobody is suggesting that.

Or you can use a system designed to accomodate the occasional failure like Akka (running on the JVM they seem to hate so much) or Erlang.

This. So much this. We restart faster than X and therefore we're better? (not to mention all the other weird points of comparison the author chose to call out)

There's plenty of languages with runtimes that have fast start-up times. Does Node therefore suck because my Go application could potentially start-up faster? What about something Erlang on Xen where they're spinning up a brand new Xen domU to service a web request in the hundreds of milliseconds range? Brand new VM, can't really "crash" and need to be restarted because it's only ever there for a single request.

I'm not really sure what the end goal of the whole article is, but it seems woefully written in terms of being technically rigorous.