I think proper compile-time type checking for Elixir would be a game changer. Here are my thoughts:
-
Thanks for doing this! I know that not everyone in the Elixir community wants static types, but I also think that some individuals and orgs are skipping Elixir altogether for exactly this reason. Since the trend in PLs more broadly seems to be towards static types, I think a good static type checker would go a long way towards ensuring Elixir’s longevity.
-
How does FB’s work on static Erlang affect your work? Can you piggyback off of that work at all? If so, would there be any benefit to waiting for that release?
-
Does the core team have any position on these efforts? It’s impossible to please all of the people all of the time, but I do think there is benefit to getting as much input as possible from key players before forging ahead. Thus far, attempts to deal with Elixir types feel a bit fragmented, as opposed to a unified effort.
As for my own input, I would be thinking about the following:
-
Compile-time checking.
-
Potential for integration with ElixirLS and IDE support.
-
Separate type declarations. Elixir function heads are already a busy space, with lots of pattern matching and such. I think inline types would make this much worse. I don’t think the type declarations have to look like
@speccurrently does, but I do think they should get their own line. -
Gradual addition to existing codebases. This isn’t particularly important to me personally, but I think it’s probably essential to wider adoption.
-
Can we leverage behaviours or another technique to achieve generics/polymorphism?
-
Have you considered how you want the community to support you? How much collaboration do you want? Given that you are doing this full time, will you be setting up Github sponsors or a Patreon?


















