Hacker News Reader

Comment by joevandyk | Hacker News Reader

Does anyone miss or want type checking when working with Elixir? After working with Ruby to build large systems for so long, I'm missing a little bit of the safety that types provide. Typescript has been great.

View on HN

I come from Scala to Elixir and I personally prefer static typing for a lot of reasons. I have come to very much enjoy the looser typing as I can write more code more quickly, serialization is less of a pain, etc. Elixir is still compiled (and you have dialyzer if you really want to go that way.) You can match on a struct type and the compiler will catch a typo if you try to access a member that doesn't exist in the struct so you can go a long way to lean on the compiler. All that said, I can attribute +50% of the bugs that hit production to things that a type system would have caught. I would prefer to go back to writing code with Scala/Akka and would choose those technologies in a blink for any system that I'm going to grow over time. development time _is_ slower with scala/akka (assuming you don't count time spent trying to refactor or fixing bugs a typesystem would catch) but it's probably an order of magnitude faster for computational tasks, not slower on concurrency related items, has a bigger/more mature eco system (which is huuuuge) and gives you OO beside FP which is highly valuable for design. The skill ceiling is higher with scala/akka so you can keep growing and learning.

And OMG trying to refactor Scala vs trying to refactor elixir?? IntelliJ is a jet powered pogostick for applying refactorings (to quote Beck) - It's very had to make large structural changes to elixir code without a static type system and tools to help you rename, extract methods and classes, and move them around. I can do things in scala I would never dream attempting without aa type system which is probably my biggest gripe for long term maintenance.

That being said, working with elixir has turned me into an Emacs junkie and I personally find a lot of value in that but it doesn't help me deliver better code faster, just gives me nerd points because I can check the weather and reply to email from my textt editor

Elixir has a specific kind of typechecking: success typing. You can set up the Erlang Dialyzer tool to work with VSCode using the ElixirLS extension. It will warn you about type errors. Success typing means that there is provably a type error and you actually need to fix it, as opposed to the more common form of typechecking wherein the compiler forces you to prove that there isn't a type error.

True to form, when I see a Dialyzer warning and think about it for a bit, I find that I always need to fix the code. The error messages do take some getting used to, though.

Isn't Dialyzer's success typing similar to TypeScript in that it's gradual typing? Or am I muddling up my concepts?

It's similar and they are both considered gradual typing, yes. Dialyzer is 'better' in some ways though. For example, consider this TypeScript:

    function f(a) { console.log(a.x); }
    f({});

With the strictest checks turned on ( try it at https://www.typescriptlang.org/play/#src=function%20f(a)%20%... ), TypeScript will give you this message: `Parameter 'a' implicitly has an 'any' type.`

Now consider the equivalent Elixir:

    def test2(), do: f(%{})
    def f(a), do: IO.inspect(a.x)

Dialyzer will give you this message: `Function test2/0 has no local return ... The call 'YourModule':f(#{}) will never return since it differs in the 1st argument from the success typing arguments: (atom() | #{'x':=_, _=>_})`

This is why I said the Dialyzer message takes some getting used to :-) But, it just means that `f` needs to be called with either an atom (because you could pass in a module to the function, and modules are modelled as atoms), or with a map object with the `x` key and possibly some other keys.

Yes and no. I also come from a similar background with the pain of building a large system in Ruby, and having been doing Elixir for 2 years since then I find it that is has the right tools to let you go either way to a degree.

I like that you have all sorts of optional tools for adding runtime type checks like guards and struct pattern matching if you want it. Using it extensively will inhibit generalizability, but it can be tremendously useful for isolating errors in problematic code paths by failing early and explicitly. Typespecs enforced by Diayzler aren't exactly a safe type system, but can help with some of the sanity checks, documentation, and linting that Typescript gives you (not really being a safe type system either).

I would say the only thing I really feel is missing is being able to check for protocol implementations and perform runtime control flow based on these.

Gradualizer supports Elixir. It will move into beta soonish :)

Reply on news.ycombinator.com