What are your concerns about a future type system for Elixir?

[wanton7]

My first concern is that static typing will not be implemented because something like compiler slowdown and hope that if slowdown happens then there would be a compiler option to compile without type checking to speed compilation instead just dropping type checking from the language.

My second concern is that if type checking is not implemented Elixir will not be as popular as it could be. I feel it’s the main thing holding Elixir adoption back and I want Elixir to be popular as possible.

[jswny]

I just meant that in the context of types, we already have some mechanisms to do type checking operations. And for the new type system, I am worried that those patterns will remain in some codebases while other codebases use the type system to do those same checks.

[sbuttgereit]

Seems there are a fair number of people concerned about community splits between those that opt into the new type system and those that don’t.

If that is addressed, there might be some useful precedence in a different community/ecosystem that might provide an analogue for us here: PHP.

When PHP first got popular it was just an imperative language. Eventually it got pretty substantial, but opt-in, object oriented development features which I believe are the now the norm in the majority of professional level PHP applications. I think what happened during that expansion of features and the community response to those features becoming available may be instructive in at least imagining what might happen with the set-theoretic type system and Elixir.

I should caveat this with I didn’t really live this PHP transition as a developer at all. Being an enterprise guy, PHP was always on the periphery of the work I was involved in, but rarely something that had my direct attention. In other words I could be off base in my thinking here.

[teamon]

I wonder if the type system will be powerful enough to allow catching three of the most common errors I encounter:

• getting nil where there shouldn’t be one
• map.key where map do not have the key
• (ecto) post.author.name where author is not preloaded - (i.e. specify that a function requires %Post{author: %Author{}} and somehow make Repo.preload smart on the return type)

[darkbaby123]

I think a dynamic-typed language + gradual type system is a perfect combination. And my concerns:

1. Will the type system take TOO long to be done (and complete)?
2. Will the type system too complicated like TypeScript’s advanced usage? I wish the Elixir types like it’s language design - simple, precise, not too magic.
3. I hope the type syntax to be more like language syntax, the experimental syntax in the paper is a little strange to me. But with strong reason I can accept it.

[yordisprieto]

Colocation
I am unsure what the trade-off would be in colocating the types externally to the function and data structure definition. I do not mind that much @spec, although annoying having to type the name in the @spec and the function definition (things like that that encourage bikeshedding and are so predominant when daily coding).
When it comes to @type and maps, I definitely prefer having something colocated. In an ideal scenario, the type system could replace/enhance defstruct.

Complexity
Hopefully, it will not be as complex as the TypeScript type system, where we end up coding rules inside of it. I lean more towards simple unions and data types and avoid anything to do with the content of the types.

Scapegoat
When in trouble, type: unknown I do it myself should be enough so hopefully, it could incrementally add it to codebases.

Type Casting
Respecting that type Nickname string is not the same as string is extremely valuable when you want to enforce a Factory Function to create a Value Object, if there is only one way to create the Nickname type then I guarantee that people are not bypassing the factories that enforce correctness.

[GenericJam]

When are types enforced? If they blow up in dev and not prod that’s a win.

One of the initial goals of Erlang was hot reloading. afaik this is why types didn’t make the cut the first time. Hot reloading is still possible in Elixir even if it’s not the blessed path. I wouldn’t want to erode that further.

If hot reloading is no longer supported that’s a significant break from Erlang.

[derpycoder]

My concerns, memified:

1. Ignoring the Type system.
   
2. Using any for datatype.
   
   
3. Generics.
   

P.S. Please don’t remove the memes, they add color to the end of discussion.

[josevalim]

Thank you everyone for sharing your concerns/worries. If folks want to continue the conversation in a new thread, you are more than welcome! Meanwhile this is more than enough to cover the most common concerns during my presentation, thank you!