Comment by toast0

> As hard as I've been on Erlang, the devops story is pretty powerful for fixing broken systems. That said, the dynamic types means I had to fix more broken systems live than I ever have for Go; I haven't missed this because my Go systems generally don't break. Still, if they are going to break, Erlang has a lot of tools for dealing with it live.

First off, I don't think you're being hard on Erlang, meerly truthful and clearly informed. Thank you for your balanced presentation.

I think this may be true (but hard to quantify) that things go wrong more often in an Erlang system than a Go system; but failure in Erlang tends to be much less painful than other environments and making changes can be much quicker and less costly. The primary reason to spend effort to avoid failure is because failure is costly; but if failure isn't costlh, you don't need to preemptively avoid it.

Of course, you can deploy your Erlang system with a lengthy process and ignore the flexibility and danger (and fun!) of hotloading, and in that case, finding failures before deployment is more important.