josevalim
Type system updates: moving from research into development
I hereby officially announce the Elixir type system effort is transitioning from research into development. Read the full-announcement here: Type system updates: moving from research into development - The Elixir programming language
This new exciting development stage is sponsored by Fresha (they are hiring!), Starfish* (they are hiring!), and Dashbit.
Thank you!
Most Liked
josevalim
There are a few details I don’t appreciate about how we implemented typespecs (for example, I find them too verbose) but the deal breaker here is that typespecs are not capable of expressing the proposed type system, so we will need something new.
lifeofdan
I had to create an account here just to say how much I love this. This is incredibly exciting!
josevalim
The type system allows us to support any literal as type but it is still undecided if we want to do that. Opposite to the Dialyzer, an actual type system will be strict about the expected arguments. Imagine this code:
$ :foo or :bar -> string
def foo_or_bar(:foo), do: ...
def foo_or_bar(:bar), do: ...
Now imagine you call it like this:
foo_or_bar(String.to_existing_atom(string))
Because you are passing any atom to the function, the type system will warn about a type error. While Dialyzer would never warn. So you would need to write this instead:
case String.to_existing_atom(string) do
:foo -> foo_or_bar(:foo)
:bar -> foo_or_bar(:bar)
_ -> raise "expected foo or bar"
end
Therefore, more specific types will require you to prove that you are passing those specific types and that may actually make the type system more annoying than helpful.
Since there are trade-offs here, it is a decision we will make later once we have a better feeling for the type system.
Correct.
OndrejValenta
Sweet Jesus, Halelujah!
Working with Elixir/Phoenix daily, you slowly get used to some level of pain and suffering, typo here, wrong return tuple here, wrong atom elsewhere. You start see it as part of the job.
But then, you switch back to ASP.NET for another project, like we do in my team, and you find out the pain is gone, there is no more suffering, you write more but you can relax, you can trust the system, if it compiles you are good, if it doesn’t it tells you right away where you made a mistake. With ReSharper and continuous compilation I can see all compilation errors right away, after every change.
As much, as I prefer Elixir/Phoenix for production systems and we introduced some into DHL, this is an enormous problem for us, the trust in the code is simply not there.
zachallaun
This is great to hear. Huge congrats to everyone involved. I’m sure I’m not the only one here eager to see these ideas translated to code. ![]()
I’d like to especially extend congratulations to Guillaume Duboc – not every PhD candidate has the opportunity for their work to make such a direct and significant impact. It must be extremely exciting!







