Do you mind sharing the name of the episode or a link to it? I don’t seem to be able to find it…

Thank you! I hope so too!

I’m going to try and only pick up short term contracts in future, as to be less disruptive to Gleam development.

One issue is that existing Elixir code will be hard to adapt to a sound type system, more specifically in how pattern matching is used. For example, consider this common idiom:

{:ok, any} = my_function()

(where my_function may return {:ok, any} or {:error, error} depending on whether the function succeeded)

Implicitly, this means “crash, via a badmatch error, if we didn’t get the expected result”. However this is basically incompatible with a sound type system as the left-hand side of the assignment has the type {:ok, T} and the function has the return type {:ok, T} | {:error, Error}.

Of course we could add some kind of annotation that says “I mismatched the types on purpose”, but then we’d have to sprinkle these all over existing code.

This is also the reason why Dialyzer is based on success typing rather than more “traditional” type checking. A consequence of this is that Dialyzer, by design, doesn’t catch all potential type errors; as long as one code path can be shown to be successful Dialyzer is happy, which reflects how Erlang / Elixir code is written.

One thing is that TypeScript is currently bursting at the seams as developers aspirationally use it as a pure functional statically-typed dependently-typed language. The TypeScript developers are bound by their promise not to change JavaScript semantics, even in seemingly minor ways (and I understand why this is so), but it really holds back TS from becoming what many users hope for it to be. There’s clearly demand for something more, and eventually a language like PureScript / Grain / etc will carve out a sizable niche.

So, I think starting over from scratch with a new language can be advantageous, as long as you have sufficient interoperability with the existing ecosystem.

I won’t go too much into Dialyzer as I’ve never found it reliable or fast enough to be useful in development, so I don’t think I’m in a great place to make comparisons. For me a type system is a writing assistant tool first and foremost, so developer UX is the name of the game.

I think the TypeScript question is a really good one! There’s a few aspects to this.

Gradual typing (TypeScript style) offers different guarentees to the HM typing of Gleam. Gleam’s type system is sound by default, while with gradual typing you opt-in to safety by providing annotations which the checker can then verify. In practice this ends up being quite a different developer experience, the gradual typer requires more programmer input and the will to resist temptation not to leave sections of the codebase untyped. The benefit here is that it is easier to apply gradual types to an already existing codebase, but that’s not any advantage to me- I want the fresh developer experience that is more to my tastes and easier for me to work with.

Another aspect is just that it’s incredibly hard to do gradual typing well. TypeScript is a marvel, but I can think of many similar projects that have failed. In the BEAM world alone I can think of 4 attempts to add a type checker to the existing Elixir or Erlang languages, and all have failed. Two of these projects were from Facebook and from the Elixir core team, so it’s not like they were short on expertise either.

Lastly, a new language is an oppotunity to try and improve on Elixir and Erlang. There’s lots of little things in Gleam that I personally am very fond of which are not possible in them.

One silly small example is that we don’t need a special .() to call an anonymous function like Elixir does.

let f = fn() { 1 }
f()

And we can pipe into any position

1
|> first_position(2)
|> second_position(1, _)
|> curried_last_position

And we have type safe labelled arguments, without any runtime cost. No keyword lists here

replace(each: ",", with: " ", in: "A,B,C")

Thanks for the questions

edit: Oh! And RE the existing ecosystem, you can use Gleam and Elixir or Erlang together! That’s certainly something Gleam has been built around.

Yes, there should be no problem. However there may be some additional work to be done in Gleam to provide typing for such functions.

Here you have docs for that. It should be also perfectly possible to call Gleam functions from other BEAM languages as well.

Thanks to the great work of Elixir and Erlang there’s a good package ecosystem which can be used by all the languages on the VM. The website has details https://hex.pm/

We use a channels abstraction to type messages, similar to Go or Rust. They can be combined to make type safe selective receives.

See the OTP library for details -> https://github.com/gleam-lang/otp

IDK how Caramel does it, but one way to do it is to type functions on the messages it can receive. This type then gets “inherited” by processes that are spawned with that function. This means all match clauses inside the function’s receive / all messages sent to the process must match the function’s “receive type”