My Future with Elixir: set-theoretic types

My Future with Elixir: set-theoretic types(elixir-lang.org)

102 points by rukenshia 3 years ago | 11 comments

xupybd 3 years ago |

I think people underestimate how powerful a tool strong types can be. If you make illegal states impossible in the type system you get a class of tests effectively enforced by the compiler.

https://fsharpforfunandprofit.com/posts/designing-with-types...

https://khalilstemmler.com/articles/typescript-domain-driven...

https://erszcz.medium.com/make-illegal-states-unrepresentabl...

josevalim 3 years ago | |

Hi, author here.

You do get a class of tests but I don't believe they are sufficient. For example, in the first article, we have this code:

    let contactFromEmail name emailStr =
        let emailOpt = EmailAddress.create emailStr
        // handle cases when email is valid or invalid
        match emailOpt with
        | Some email ->
            let emailContactInfo =
                {EmailAddress=email; IsEmailVerified=false}
            let contactInfo = EmailOnly emailContactInfo
            Some {Name=name; ContactInfo=contactInfo}
        | None -> None

While the types tell me that an email can be valid or not, and that the function may or may not return a contact, it does not tell me _which values_ will lead to those scenarios. The extrapolation is that this function could always return `None` and that would be alright from the point of view of types.

So perhaps you should still test that a valid email returns `Some contactInfo` and an invalid one returns `None`? Or maybe you have thoroughly unit tested `EmailAddress.create` and you feel confident in skipping tests here? Or perhaps you may want to test that `IsEmailVerified` is set to false (or maybe you even have logic that may set it to true in certain cases)?

In a nutshell, types would replace tests that assert on the states, but those are not the tests I write in the first place. The tests I write would rather focus which values give me certain states and assert which values inhabit those states.

pdhborges 3 years ago | | |

This code example doesn't make much sense. There is already a type to represent a valid email address (EmailAddress), why are we creating a function to make contacts that receives an email as a string. Just change the function to receive EmailAddress in the first place and avoid all the matching mess.

abrookewood 3 years ago | |

I think Jose does a pretty good job of explaining how the expect benefits of Types would or would not apply to Elixir.

AlchemistCamp 3 years ago |

> "At this point in time, it seems the overall community would prefer a system that flags more potential bugs, even if it means more false positives."

I'm not sure this is true. While people who want static types are vocal about it , those who are happy with Elixir's current balance of dynamic typing with help from guards and pattern matching are generally quieter since they're well served by the language. At least of the Elixir devs I know, the overwhelming majority are not looking for a typed language. On the contrary, many of them moved to Elixir from Java or TypeScript because they didn't like the rigidity.

It's primarily people who haven't ever really used Elixir or Erlang for significant work that make the most noise about "needing" static types. There are some exceptions, but for the most part this is the dynamic I've seen.

dmpk2k 3 years ago |

> so we should not expect any meaningful performance gain from typing Elixir code

but

> The Erlang compiler already does so to improve performance within a single module and we want to eventually do so across modules and applications too.

A bit confused by this. Will Elixir potentially embed types in BEAM files like Erlang increasingly does to inform the JIT, or not?

josevalim 3 years ago | |

That's a very good question. We could potentially do it, yes, but we would have to carefully benchmark and the benefits would still be limited to single modules (no cross module optimizations at the moment). So overall it is safest to not expect any meaningful gains. You will likely gain more by writing idiomatic code with patterns and guards. :)

mamp 3 years ago | |

I read it as even if extra type information was there the BEAM doesn’t use type information to optimise across modules.

tommica 3 years ago |

I write PHP and being able to give the arguments a type is such a nice thing, especially for self-documentation - hopefully this brings similar things to elixir, I really want to work with the language.

Besides that I wish for a really good LSP or other way to integrate to IDEs, especially to be able to jump to functions and see how they work exactly.

JediLuke 3 years ago |

I’m just gonna say this - Elixir flat out does not need strong typing. People who think it does, need to learn how to use structs, guards & change sets properly. 99.9% of the time we are interested in “Accounts” or “widgets”, if it’s important enough to be in your domain model you can spend 2 minutes creating a struct for it, boom no need of types. I realize some very smart people work on Gleam and such, and I don’t really want to claim I know more than them, but seriously I think if you find yourself reaching for types in Elixir you just don’t grok that it’s a high-level language and types will only get in the way! Stop thinking like a C/python/JS programmer, start thinking like a prolog/lisp programmer!! We want to get away from worrying about ints vs floats and deal with high-level constructs that match our domain model, NOT regress into strict typing.

let contactFromEmail name emailStr = let emailOpt = EmailAddress.create emailStr // handle cases when email is valid or invalid match emailOpt with | Some email -> let emailContactInfo = {EmailAddress=email; IsEmailVerified=false} let contactInfo = EmailOnly emailContactInfo Some {Name=name; ContactInfo=contactInfo} | None -> None