Comment by hmmokidk | Hacker News Reader

Comment by hmmokidk | Hacker News Reader

Parent Full thread

The hottest news in the Elixir community is that it is currently experimenting with set theoretic type / gradual typing. Some french PHD is working on it.

It is past the RND phase and in development at the moment.

It is highly experimental and not guaranteed to ship with the next version of Elixir. Right now the idea is to see if it offers any value in the first place. There are a lot of statements about what types offer. What the Elixir team wants to do is actually experiment to see if there's a benefit. Which is a really neat thing for a lang to do...to actually experiment like that is incredible.

As for right now, in a sense yes. It has this thing called Dialyzer - https://www.erlang.org/doc/apps/dialyzer/dialyzer_chapter.ht... which is a static analysis tool. This offers some non runtime type guarantees. But it is still a dynamically typed language. And the community is split on it IME. The errors are cryptic and there are some other issues. There's also Norm.

There are some things you can do to guarantee types during runtime, like match a function to a type. So when called with a string the implementation is different than with a boolean. So there are some run time type guarantees.

example of matching (return a diff string if bool or if nil):

def do_thing(n) when is_bool(n): "some boolean"

def do_thing(n) when is_nil(n): "nil"

There's also the concept of a struct which is like a typed object / map / key value pair thing.

> The hottest news in the Elixir community is that it is currently experimenting with set theoretic type / gradual typing. Some french PHD is working on it

To expand on it: you can read the proposal[0] or watch the video presentation by the author[1].

It is a very similar system to Typescript, with (at the first glance) only minor differences: "any" becomes "term", primitive constants are not singleton types (so you cannot write programs with type system alone... yet), and I expect some edge cases around generics will be handled differently (especially since you cannot specify types yourself in function calls, i.e there is no myFunction<MyType1, MyType2>()).

On the other side, there are some things that the proposal seems to be doing better than Typescript. It handles type assertions without the need for "function isX(maybeX): asserts maybeX is X { ... }" and since pattern matching plays important role in Elixir, I expect it will have a lot of polish around that.

[0] https://arxiv.org/pdf/2306.06391.pdf

[1] https://youtu.be/gJJH7a2J9O8

To show the struct example:

    def do_thing(%Foo{} = foo), do: foo

Here `foo` has to be type of struct `%Foo{}`.

    def do_thing(%Foo{bar: "baz"} = foo), do: foo

Here `foo` has to be struct `%Foo{}` with field `:bar` with the value of `"baz"`.

Another one I like to point out is how operators aren't rampantly overloaded.

    def add(a, b), do: a + b

This will _only_ work with floats or integers because `+` only works on those types. String concatenation, adding lists, date math, etc have their own operators/functions.

While Elixir does offer mechanisms to overload operators, you have to be very explicit about it. There is no way to globally redefine `+`, for example. It would be on a per-module or even per-function basis (and not something that is done too often, though there are some good uses of it out there).

Dynamic typing in Elixir really isn't that big a hinderance if you stick to its idioms. That said, I'm fairly excited about the prospect of the type system.

Reply on news.ycombinator.com