My Future with Elixir: set-theoretic types(elixir-lang.org)
elixir-lang.org
My Future with Elixir: set-theoretic types
https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/
12 comments
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:
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.
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
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.
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.
I agree,
You can /always/ go from `f : t -> r` to `f' : t option -> r option` with `Option.map` (ML-syntax, translate to w/e type syntax you're most familiar with), but the reverse is not true.
I think that the example is super-simplified though and I think that the central point still stands if you have multiple errors though.
You can /always/ go from `f : t -> r` to `f' : t option -> r option` with `Option.map` (ML-syntax, translate to w/e type syntax you're most familiar with), but the reverse is not true.
I think that the example is super-simplified though and I think that the central point still stands if you have multiple errors though.
I think Jose does a pretty good job of explaining how the expect benefits of Types would or would not apply to Elixir.
> "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.
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.
> 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?
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?
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. :)
I read it as even if extra type information was there the BEAM doesn’t use type information to optimise across modules.
[deleted]
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.
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.
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.
https://fsharpforfunandprofit.com/posts/designing-with-types...
https://khalilstemmler.com/articles/typescript-domain-driven...
https://erszcz.medium.com/make-illegal-states-unrepresentabl...