As someone who uses and loves Elixir, I'm not excited at the thought of a tour system that potentially goes beyond the compiler. Type checking is possible using spec annotations, and is a feature...
As someone who uses and loves Elixir, I'm not excited at the thought of a tour system that potentially goes beyond the compiler. Type checking is possible using spec annotations, and is a feature from the underlying language that you see frequently used in Erlang projects. I like the idea of extending that to be capable of inferring types from structs and such, and I'd love greater compiler integration (I think type checks are a separate operation altogether), but I hope they don't make it get on the way of people continuing to use Elixir as they do today.
It's interesting stuff though. And I am hopeful that more compiler checks will make compiled code even more immediately reliable.
I do agree that it would have been ideal to work together with typespecs instead of something new and parallel to it. However in my Elixir experience (intermediate level) I find type checks very...
I do agree that it would have been ideal to work together with typespecs instead of something new and parallel to it. However in my Elixir experience (intermediate level) I find type checks very finicky, and it's hard to even know how to use Dialyzer much of the time. It IMO requires quite an investment of time just to figure out Dialyzer setup.
Therefore I would assume that the creator of the language and the research team, all with deep knowledge of all of this, encountered issues integrating with Erlang typespecs at deep enough, and performant enough, of a level to be useful for the things they wanted to achieve. In particular typespecs may be too flexible in some ways, and not actually be that useful in automated refactorings and many kinds of static type checks.
I'm excited for this research, as refactoring Elixir has proven to be a major pain point, and static types will go a long way in helping with automated tools like that.
Side note: Gleam has potential as an R&D project, but IMO goes a bit too extreme. It's not only statically typed but also completely changes the syntax to be Swift-like. It's hard for me personally to wrap my head around how to integrate Gleam code with Elixir and Erlang, although admittedly I haven't invested much time into that.
On the other hand, although Elixir syntax is obviously a major departure from Erlang, at the same time it maps very clearly 1-to-1 to Erlang code.
To me, Elixir adding static typing will be a truly major achievement, while at the same time being of minimal friction to adoption, due to everything being optional.
Yeah, I much prefer the syntax of elixir, so I'm not keen on something like Gleam. But I'll be keeping my eye out for this as it releases gradually. Jose is a smart person, so I'm sure it'll be a...
Yeah, I much prefer the syntax of elixir, so I'm not keen on something like Gleam. But I'll be keeping my eye out for this as it releases gradually. Jose is a smart person, so I'm sure it'll be a well-baked implementation.
Strictly speaking, dialyzer goes beyond the compiler as it offers type analysis on bytecode. I think that the intersection approach pioneered here will be a major improvement over many existing...
Strictly speaking, dialyzer goes beyond the compiler as it offers type analysis on bytecode. I think that the intersection approach pioneered here will be a major improvement over many existing approaches. Ideally, your remark about inference will prove to be prescient in the way that TypeScript's inference works. Granted, both dialyzer and TypeScript are intentionally unsound, so maybe not the best example.
As someone who uses and loves Elixir, I'm not excited at the thought of a tour system that potentially goes beyond the compiler. Type checking is possible using
specannotations, and is a feature from the underlying language that you see frequently used in Erlang projects. I like the idea of extending that to be capable of inferring types from structs and such, and I'd love greater compiler integration (I think type checks are a separate operation altogether), but I hope they don't make it get on the way of people continuing to use Elixir as they do today.It's interesting stuff though. And I am hopeful that more compiler checks will make compiled code even more immediately reliable.
I do agree that it would have been ideal to work together with typespecs instead of something new and parallel to it. However in my Elixir experience (intermediate level) I find type checks very finicky, and it's hard to even know how to use Dialyzer much of the time. It IMO requires quite an investment of time just to figure out Dialyzer setup.
Therefore I would assume that the creator of the language and the research team, all with deep knowledge of all of this, encountered issues integrating with Erlang typespecs at deep enough, and performant enough, of a level to be useful for the things they wanted to achieve. In particular typespecs may be too flexible in some ways, and not actually be that useful in automated refactorings and many kinds of static type checks.
I'm excited for this research, as refactoring Elixir has proven to be a major pain point, and static types will go a long way in helping with automated tools like that.
Side note: Gleam has potential as an R&D project, but IMO goes a bit too extreme. It's not only statically typed but also completely changes the syntax to be Swift-like. It's hard for me personally to wrap my head around how to integrate Gleam code with Elixir and Erlang, although admittedly I haven't invested much time into that.
On the other hand, although Elixir syntax is obviously a major departure from Erlang, at the same time it maps very clearly 1-to-1 to Erlang code.
To me, Elixir adding static typing will be a truly major achievement, while at the same time being of minimal friction to adoption, due to everything being optional.
Yeah, I much prefer the syntax of elixir, so I'm not keen on something like Gleam. But I'll be keeping my eye out for this as it releases gradually. Jose is a smart person, so I'm sure it'll be a well-baked implementation.
Strictly speaking, dialyzer goes beyond the compiler as it offers type analysis on bytecode. I think that the intersection approach pioneered here will be a major improvement over many existing approaches. Ideally, your remark about inference will prove to be prescient in the way that TypeScript's inference works. Granted, both dialyzer and TypeScript are intentionally unsound, so maybe not the best example.