How to bring Elm's safety to Haskell?

[rtfeldman]

If you like elm you will probably like it even after first weird runtime exception. But you were promised not to have them. And they will stay with you for a long time.

What the website says is:

Unlike hand-written JavaScript, Elm code does not produce runtime exceptions in practice.

This is an honest assessment based on the experience reports I’ve heard and continue to hear.

Yeah, there are compiler bugs, you can always run out of memory, etc. People point out all the time that it’s technically possible, or maybe a regex exploded in development once. But when I ask people if they have experienced runtime exceptions in their own production Elm code, in practice, what I hear over and over again is a whole lot of “no, never.” We still haven’t, even once, after 240,000 lines of code running in production for coming up on 3 years.

Maybe you’re an outlier in this regard, and you actually do run into this. If so, fair enough! You know your own experience better than I do. But you said “one of the things I value highly is honesty” and I don’t think you’re exposing some hidden truth by telling people they should expect to be disappointed by this claim, when the overwhelming weight of experience says that they should expect the opposite.

[turboMaCk]

But you said “one of the things I value highly is honesty” and I don’t think you’re exposing some hidden truth by telling people they should expect to be disappointed by this claim when the overwhelming weight of experience says that they should expect the opposite.

Fair enough I should probably clarify. Frankly, I’m not even sure if any runtime exception made it to production, maybe not. Few made it to staging. One thing that did make it to production was a bug in vdom in IE but that just made some things not working without exception. I never tried to say that in practice you have tons of production exceptions but maybe I wasn’t clear enough.

The problem with runtime exceptions in elm is that when you encountered them for the first time you have no idea what is wrong and how to fix it.

I’ve meant during development. Maybe I should have been more explicit about that.

This is what sub-headline on the web says though:

Generate JavaScript with great performance and no runtime exceptions.

I’m not saying I have a big issue with this statement. It’s definitely fine for communication to some audiences. That’s why @MarkHamburg said to attach a little bit of realism. Nobody used world like lie.

Yes, there is a big difference between Elm and Haskell safety. Haskell has partial functions in std library and those functions are partial by design (like head). In elm, exceptions are mostly due to bugs in implementation not by design (with exception of regex which is an understandable mistake).

I wanted to support Mark because I agree with what he said even though I didn’t find it necessary to bring it to table myself. It is a reaction on things that were said within this thread (therefore there are quotes) not primarily on what elm web says. The web was used just to give some context to claims mentioned in here.

We still haven’t, even once, after 240,000 lines of code running in production for coming up on 3 years.

is incredible and I hope you will keep on being that successful

[rupert]

I’m very happy that Elm does not have the concept of ‘exceptions’. I believe in Haskell they are not fundamentals of the language, but described within the language. In ML exceptions are a fundamental of the language.

Java has a checked IOException for dealing with IO errors that may be encountered when dealing with IO devices which are necessarily potentially unreliable. In Elm, the equivalent of a checked exception is a Maybe or a Result.

Is this not true in Haskell too? IO errors are described by checked exceptions? So the code must deal with all possible outcomes and this is enforced by the type checker?

[rtfeldman]

Fair enough, thanks for clarifying @turboMaCk! ️

[turboMaCk]

Your comment made me realize that I haven’t used word exception right as I intend to talk generally about runtime errors. Not sure if that word was the right one to use in everything I wrote.

To the point:

The Haskell 2010 type for exceptions in the IO monad. Any I/O operation may raise an IOError instead of returning a result. For a more general type of exception, including also those that arise in pure code, see Exception.

In Haskell 2010, this is an opaque type.

from https://hackage.haskell.org/package/base-4.10.1.0/docs/System-IO-Error.html

In addition to exceptions thrown by IO operations, exceptions may be thrown by pure code (imprecise exceptions) or by external events (asynchronous exceptions), but may only be caught in the IO monad.

from https://hackage.haskell.org/package/base-4.10.1.0/docs/Control-Exception.html

Those are exceptions and you’re right it’s part of type system.

However converstaion in here was about unsafety of functions on lists like head.

Those are called partial functions. Such functions do not exist in Elm’s std lib but are user definable with use of Debug.crash (which will require flag in next version of compiler).

I think full answer to your question is here: https://wiki.haskell.org/Handling_errors_in_Haskell

Btw this might be also interesting insight outside of functional word (just be critical to what Jonathan says) https://www.youtube.com/watch?v=EVhCUSgNbzo