Facebook is writing a new, statically typed language to run on the BEAM?!

[stefanluptak]

I stumbled upon this tweet by @devonestes and I find this information very interestnig. I hope we could discuss it a bit more here.
What do you think about it?

[rvirding]

Yes, I have heard a bit about it. It is not so much a new language but adding static typing to Erlang, Erlang2.

[dimitarvp]

Has the problem about the blackboxing of messages been figured out when it has to work in a statically typed context?

[Qqwy]

Which problem are you referring to?
The problem of processes being able to receive any message regardless of type that requires extra care to handle in a statically typed context? Or something else?

[dimitarvp]

That, yes. I remember it was said that statically typed Erlang turned out very hard to implement due to the OTP model (namely that any process can receive any message).

[kokolegorille]

You might be refering to this post.

How hard would it be to have a static typing system in Elixir?

I just want to confirm what has already been mentioned a number of times in this thread: the reason for not having static typing in Erlang was the absolute need for doing dynamic code upgrades of running systems. This was an absolute requirement and if we couldn’t do it then our language/system wasn’t interesting. There aren’t many systems using it today as most try to do rolling upgrades but we didn’t have that option back then so we had to be able to upgrade a running system. Remember we are t…

[dimitarvp]

Seems that this coin has more than two sides then. Thanks for the pointer!

[stefanchrobot]

I’d love to see a fast, gradual type checking introduced into Elixir. If I’m not mistaken and the project is successful, the solution would have to be reimplemented in/for Elixir. Looks like neither Dialyzer nor Gradualizer will save me from things like this:

case Integer.parse("123a") do
  {int, ""} -> int
  :error -> :failed
end

Assuming that I do want a warning here, having this caught by a type checker would be a great win. On the other hand, I feel that bringing an overly complex type system would kill all the productivity of Elixir.

I’m looking forward to what the WhatsApp team comes up with, though it’s a bit mixed with a fear of community fragmentation.

[dimitarvp]

Do you guys have any plans for Erlang2 that you are ready to share? Or is this solely a Facebook project and nobody called you?

Having a statically typed Erlang would be amazing but I imagine there will be tradeoffs.

[rvirding]

So far it is a Facebook project. I expect we will find out when they get further with their work.

[Qqwy]

Exactly.
The ‘a process could receive any message’ problem can be resolved in static languages by making all receives selective receives. If you receive a message you do not understand, you always have the option to decide whether to (a) crash the process, (b) totally ignore it, or © handle it in some generic way. This is true both in dynamic and static languages.

The main reason the problem keeps coming up, however, is because the way OTP is structured is very much as a set of partial functions; a GenServer responds only to certain call/casts itself (and others fall back to the default implementation of crashing or doing nothing). Proper static type-checking for this kinds of dispatch is however difficult, meaning that the OTP behaviours cannot be used as-is.
It might be possible to build some clean replacement abstractions that suit a statically-typed language better, but this is a non-trivial problem. Maybe row-polymorphism or other higher-order typing constructs might be useful here?

However, when we come to hot code reloading, then we up the difficulty one more level:
Hot code reloading is a much more difficult problem to solve, because it is much more difficult to ‘upgrade’ types from the old version to the new version in a statically-typed system.

[stefanchrobot]

@Qqwy

However, when we come to hot code reloading, then we up the difficulty one more level:
Hot code reloading is a much more difficult problem to solve, because it is much more difficult to ‘upgrade’ types from the old version to the new version in a statically-typed system.

I’m really hoping for a type system in the spirit of mix release - simple, yet covers >90% of the cases.

[alavrik]

WhatsApp Erlang team member here. We are planning to give two presentations at Code BEAM STO and share concrete details then. If the conference ends up being postponed until much later date, we’ll figure out a different way to do it, of course.

At this point I can only tell that we are very excited about building a first-class static typing capability for Erlang. We are also determined to do things right from both technical and community aspects. At the same time, we don’t want to mislead anyone by communicating details before we are ready to do it.

[dimitarvp]

Appreciate you chiming in! We’ll all be eagerly awaiting.

I’m especially looking forward to know what kind of a typing system you guys will pick. If it’s what OCaml and/or Rust have then I might scream like a little girl

In all seriousness though, adding static typing, no matter the kind, is going to shoot Erlang/Elixir into the future.

[AstonJ]

Welcome to the forum Anton!

I have to ask… are you using Elixir at WhatsApp at all?

Also in case you find it of interest, there’s also Gleam, a statically typed language for the Erlang VM (perhaps its creator, @lpil, could help in some way) and I believe @josevalim also mentioned the Elixir core team were investigating static typing. There are also a lot of threads here about static typing that you might find interesting:

• Topics tagged static-types

• Topics tagged static-typing

• Search results for 'static typing' - Elixir Programming Language Forum

Please keep us updated on how you get on and if you’d like more involvement from the community here please don’t hesitate to start some threads

[alavrik]

@AstonJ Good to be here! Thank you for the pointers, I’ll take a look. We are actually connected with @lpil and members of Core Elixir team. We’ve been in touch with them about static typing.

[stefanchrobot]

@alavrik @michalmuskala this is getting really exciting!

[Onor.io]

I truly appreciate it when you share your knowledge of how Erlang was built Robert. I have to say that you, Joe (RIP) and Mike are my coding heroes. Building something for a very practical purpose that turned out to be incredibly useful far beyond the original context. What a great work of engineering!

[dimitarvp]

BTW, one thing your team might also include in your backlog with the tag of “some day” – some proper sandboxing for Erlang2 (and its corresponding BEAM VM 2) would be nice.

The BEAM VM is, theoretically, ideal for certain deployments where people would like to reuse the same VM instance to run a lot of unrelated code together (say if you want a dedicated Erlang/Elixir hosting). However, currently there’s no security model built in at all (take Process.list/0 for example). I for one would be extremely happy to see an ability in the BEAM to load N apps, each isolated from one another.

I am aware this might be extremely difficult but thought I’ll just throw the idea in the ring.

[tme_317]

@alavrik

We are planning to give two presentations at Code BEAM STO and share concrete details then. If the conference ends up being postponed until much later date, we’ll figure out a different way to do it, of course.

Was curious if you are ready to share any details about progress on this exciting project since Code BEAM STO was postponed to September? Hopefully at the virtual Code BEAM end of May?