[pmarreck]

LOL. This only makes sense if you can know all the ways your code will fail... which you cannot.

Erlang/Elixir's approach is to simply say, "It's gonna fail no matter how many precautions we take, so let's optimize for recovery."

Turns out, this works fantastically in both cellphone signaling, which is where OTP originated, as well as with webserving, where it is perfectly suited.

[tossandthrow]

I don't know who are arguing with? Everyone loves the otp.

It just does not catch logics errors.

[em-bee]

whether that matters or not depends on whether the logic error occurs because of a rare combination of events or as a result of a certain state and whether that state remains after recovery. if there is for example a logic error that causes the app to crash after say 10 minutes of runtime, or eg. at a certain message size, then a recovery will reset the runtime and it will work again. it will of course invariably fail again after another 10 minutes or when the same message is resent, because it is a logic error, and logic dictates that the error won't go away no matter how often you restart, but it will work in the meantime.

in other words, any error that doesn't occur right at start can be recovered from at least for all those operations that do not depend on that error being fixed.

[tossandthrow]

This sound like a wild and very contrived argument.

Both because that memory leaks are normal is types languages - and does usually not matter in most serious applications - and because this class of errors is usually not what types catch.

Types have value when you 1) refactor and 2) have multiple people working on a code base.

The error you see when you don't have types is something like a BadArityError.