[Skinney]

The difference here, is that a lazy programmer, when forced to handle this particular case, would use "Debug.crash 'should not happen'", which causes the Elm application to crash at runtime. The TypeScript program doesn't force you to deal with it, so the lazy programmer can assume everything works, no exception is raised, and you're now running with invalid state.

To catch this bug in TypeScript, you'd have to write runtime validation, which you are less likely to do, since you can just do JSON.parse. Elm, again, forces you to write runtime type validation, and handle the potential error (which could be something simple as crashing the entire application).

When it comes to reliability, that makes all the difference.

And I'm not arguing that Elm is great because of poor developers either. I do theese sort of things when I write typescript, simply because I just don't think about the error case that often. Elm is a wonderful straight jacket that makes me a better developer <3

[hudon]

> Elm, again, forces you to write runtime type validation

But it does not force you to handle failures correctly (as your lazy programmer example proves). Forcing you to handle a Left value from an Either type is not the same as forcing you to handle a Left value correctly.

Elm doesn't save you from bad failure handling, which is what the post I replied to claimed.

What Elm does do is remind you that you should handle failures, which I think is very valuable and I'm not arguing against (and is what you're arguing for). But you still need to write a correct handler, and Elm won't force you to do that!

[Skinney]

The original post did not make that claim. It said Elm made you handle errors where they can happen. It said nothing about handling it well. Typescript will not remind you every where an error will happen, and so it is very likely that you do not handle every error, even if it is your intention to do so.