Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Future with Elixir: set-theoretic types

elixir-lang.org

Post reply on HN
Print view View original

1–10 of 13 posts

Re: My Future with Elixir: set-theoretic types

#3

Post by dmpk2k »

> 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?

Re: My Future with Elixir: set-theoretic types

#4

Post by xupybd »

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...

Re: My Future with Elixir: set-theoretic types

#5

Post by abrookewood »

xupybd wrote: post #4

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...

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

Re: My Future with Elixir: set-theoretic types

#6

Post by JediLuke »

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.

Re: My Future with Elixir: set-theoretic types

#7

Post by mamp »

dmpk2k wrote: post #3

> 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?

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

Re: My Future with Elixir: set-theoretic types

#8

Post by josevalim »

xupybd wrote: post #4

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...

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.

Re: My Future with Elixir: set-theoretic types

#9

Post by josevalim »

dmpk2k wrote: post #3

> 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?

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. :)

Re: My Future with Elixir: set-theoretic types

#10

Post by pdhborges »

josevalim wrote: post #8
xupybd wrote: post #4

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...

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…

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.
Post reply on HN