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

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!

17 Likes

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.

8 Likes

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? :slight_smile:

19 Likes

And there is a job opening: https://www.facebook.com/careers/jobs/229713254864749/

Our team works on the Erlang programming language, libraries and tools. Our mission is modernizing and improving Erlang, and making it more efficient for WhatsApp and beyond.

Our biggest and the most challenging project is evolving Erlang into a modern statically typed programming language.

Our work is motivated by extremely successful and large-scale application of Erlang at WhatsApp. Our Messaging Infrastructure that powers fast and reliable message delivery for 2B+ users is written in Erlang.

8 Likes

Oh, seems it’s going to happen soon :popcorn:

3 Likes

Perhaps static typing on the BEAM backed by a huge company is the missing link for wider adoption… I’m hopeful, we’ll see.

On another note, @rvirding has mentioned multiple times that dynamic typing was the solution to hot code upgrades, so I’m wondering if that property of erlang will be preserved- and also what other trade-offs had to be made (if any).

While the language can be typechecked, the runtime can remain “untyped”.

4 Likes

Well , thanks to Facebook the PHP core team finally decided to go full steam ahead and the result was PHP 7, that with types and without the JIT compiler from Facebook HACK was as faster. Maybe they felt “embarrassed” by how fast HACK was and how fast it was gaining traction.

Maybe with this move Facebook will also trigger a reaction from the Erlang core team to finally solve one of the major “defects” of the BEAM ecosystem, or maybe they will join forces?

1 Like

Please file bug reports and “defects” here: https://bugs.erlang.org/browse/ERL-1345?jql=project%20%3D%20ERL.

3 Likes

I wrote it in quotes because they are not bugs or defects in the strict meaning of the word, but rather decisions that were made earlier in the context of what the language was created for, but that harm its evolution and adoption in the present.

NOTE: I am not an Erlang developer, just learning Elixir, but I think that both my concerns apply to Erlang and Elixir, but correct me if I am wrong.

The main “defects” for me are:

The usual lack of static typing, and please don’t tell me about Dializer, because it’s not what people look for when they want static typing. You can say that is a strong dynamic typed language, but well I don’t want to go down that path, because we will not agree at any point in time.

Not easy to deploy as a standalone binary like Rust or Go.

2 Likes

On the subject:

3 Likes

Hello everyone! A quick update on this.

I gave a talk at Code BEAM V last Thursday in which I explained motivation for our work on static typing for Erlang, and shared some very high-level details.

Please see slides from my presentation: https://codesync.global/uploads/media/activity_slides/0001/03/f2292f201aa6b04db8c4e0b9cfa191dd07c9ee14.pdf

I expect the video of the talk to be published soon. I’ll share a youtube link once it’s out.

We’ll be sharing more details about our work on static typing for Erlang during the Code Mesh conference in November. My colleague @ilya-klyuchnikov is giving a talk on this. Here’s an early announcement: https://twitter.com/CodeMeshIO/status/1301159305480155139

We are also planning to open-source an early prototype around that time. Stay tuned!

23 Likes

Thanks to everyone at FB/WA working on this.

I’m interested to hear how community members feel this will play out in the Elixir space. Is it expected that static Erlang will be a compilation target for static Elixir, or that Elixir devs could simply use the Erlang syntax for types and pass it straight through to the compiler? I don’t anticipate that I’d be willing to trade Elixir for Erlang just to get types, but I do feel like many Elixir community members (including myself) would be very anxious to use these static types if it’s feasible.

3 Likes

I’m looking forward to this, and I’m really eager to see if it’s just types for the sake of type checking, or if we can actually do something about the types, like protocols with static dispatch, module types to make sure that the module behind an atom provides a set of functions, etc.

1 Like

Video for the talk is here https://youtu.be/RHnjPW4YOrs

4 Likes

One potential benefit is also performance? - given BeamAsm is coming out - down the line (if I understand correctly) a static typed lang can enable more optimizations to happen in the JIT? and thus perform significantly better…

If I’m not mistaking I think performance is what will drive us all toward a static typed BEAM lang… (in a few years obviously)

2 Likes

Hello all! A lot of people have been asking us about this lately - thank you for all your interest! It is a good time to give an update on this.

We were planning to release an early prototype in November, but unfortunately things are taking longer. Typing Erlang is a hard problem! We are actively working on it, but at this point we are not ready to commit to any timeline for open-sourcing it. We’ll keep the community posted as we make progress on this.

To share a bit more details. We made good progress on prototyping, and now approaching solving the most difficult problem - figuring out an efficient path for adopting static typing for existing Erlang code. Solving this problem may influence the design. In the end, we decided that we need to get a good grasp on the technical direction before open-sourcing and sharing technical details.

27 Likes

fwiw, my main interest in static typing for Erlang is dev efficiency. That’s a hard enough problem that it’s probably easiest solved with singular focus.

I’ve never been more efficient than in elixir. Same goes for pretty much any Lisp.

What code took me longest to write? purescript (essentially a slight evolution of Haskell). You can write extremely concise code but the endless type headaches and obscure error messages… I never felt less efficient. Every line of code seemed like a hard-won battle. And whenever I needed to rewrite something, the effort to reframe an idea was huge.

Which is funny because the Node.js project I had started from had not suffered from this problem. I love purescript but its elegance comes at a hefty price.

I personally think type systems are overrated, really. For me it would be sufficient if an API could selectively enforce type restrictions at its boundaries. Anything else just quickly erodes the creative process of shaping and rewriting the code.

2 Likes

For me it would be sufficient if an API could selectively enforce type restrictions at its boundaries.

Something like https://github.com/keathley/norm ?

2 Likes