It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.
Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.
JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.
Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.
Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).
But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.
Bottom line: Converting runtime exceptions to logical errors is a very bad trade.
I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.
I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.
Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.
