
“Evolving Erlang into a modern statically typed programming language” - lobo_tuerto
https://web.facebook.com/careers/jobs/229713254864749
======
markholmes
How? This is just a link to a Facebook job post.

Guess this is a good time to plug Gleam though (along with Dialyzer, which has
already been mentioned), a statically typed functional programming language
which compiles to Erlang.

[https://gleam.run](https://gleam.run)

~~~
plinkplonk
From the Gleam FAQ

"How is message passing typed?

Gleam doesn't currently have first class support for the BEAM's concurrency
primitives such as receive, send, and spawn. This is because research is still
ongoing as to the best way to apply a strong type system to them while still
enabling established OTP patterns. For now these primitives should be used via
the Erlang FFI, making them dynamically typed.

Many OTP patterns such as gen_server are functional in nature and don't
require direct use of these primitives so these behaviours can be implemented
in Gleam today."

I suspect the FB language might solve this.

~~~
lpil
Hi! I'm the author of Gleam. We have type safe actor libraries now :)

I'm interested in what the WhatsApp team come up with here too! I'm not sure
it's possible to "solve" this entirely though, message passing in Erlang is
extremely dynamic and some of the problems are not possible to solve (i.e.
distributed message passing) and will always require some unsafe type casting.

------
gilmi
Purerl (erlang backend for purescript) is worth a mention in this context:

[https://codesync.global/media/purescript-on-the-beam-
typed-o...](https://codesync.global/media/purescript-on-the-beam-typed-otp-
for-greatness-cmldn19/)

------
olodus
As I've had the privilege to study under some of the people who have been very
deeply involved in Erlang and BEAM development I've heard stories of repeated
endeavours trying to put type system onto Erlang. None ended up with a
satisfactory results.

So other ways of handling the situation was developed. That is one of the
reasons it got a very good QuickCheck lib for example.

On the other hand I would be super happy if this would end up with a nice
result. Typed Erlang would be awesome. That is why I am as hopeful for Unison
as I am.

------
covid17
Very interesting. As i know Erlang cant be statically typed because of its
patterns.

I recon they just plan on making a typesystem like typescript ontop of erlang
that is simply compiled away before building.

This way youd get the same typesafety typescriot gives you with the option of
any types that fit erlang.

------
transfire
Sounds like a dream job to me, if only I had more of the relavent experience.

The outcome of this work could prove very significant -- I'm envisioning
impressive code execution speed ups.

~~~
conradfr
How many people in the world really qualify for this role though, and want to
work for Facebook, and in London?

But yes it would be great for Erlang/Elixir.

------
dochtman
So after forking PHP, they're now going to fork Erlang, too?

~~~
smabie
And ReasonML. Not a fork exactly, but still.

------
dialyzer
Erlang already has dialyzer. Are they making another dialyzer?

~~~
logicchains
There's a difference between a linter that's capable of catching some type
errors and a full modern static type system. Compare e.g. MyPy with
TypeScript. Dialyser reduces runtime type errors; a full type system can
eliminate them.

~~~
toast0
The nature of BEAM as a distributed system makes it hard to guarantee
anything. If another node running code outside your analysis set sends you a
message you can't know what it will be at analysis time.

There could be many reasons for the sending code to be outside your analysis
set. The sending code could be in another distinct code module (perhaps in a
3rd party library). The sending node may be running an older version of the
code. The sending node may be running a newer version of the code. Something
terrible could have happened on the sending node.

~~~
kilburn
I don't see how this is different than any other IO in most systems today. For
instance, the moment you make an http request you can't possibly know for sure
what kind of response you'll get back.

However, you can strongly type your way from "string of bytes" all the way to
"a Pet record" by parsing, and the calling side just receives a strongly typed
result on the lines of "Result<Pet, Error>".

Why couldn't you do the same thing in BEAM?

~~~
dnautics
It's not that simple. What if the sending process is a human operator trying
to introspect your system with a remote console, and a slightly misspelled
token is sent? What is the right thing to do? Drop the message? Crash?

Sometimes one thing is the right thing to do and sometimes the other. But
messages are such a low level concept in erlang... It's really hard to make a
strongly typed system that doesn't pick one over the other, which is going to
be the wrong answer half the time.

I'm not saying it can't be done, but many have tried and no one has succeeded
yet.

~~~
zachrose
I believe the right thing to do is to parse the response “into” an error and
pass it to the error-handling branch that your compiler required when the
handler was written.

Or at least, that’s how it works in the statically typed language Elm, which
guarantees that your compiled code will not throw any runtime errors.

~~~
marci
For those who want Elm + Erlang/Elixir, there's Elchemy

[http://elchemy.neontree.pl/new](http://elchemy.neontree.pl/new)

------
freepor
It bothers me how much good computer science Facebook does with the proceeds
from something that has basically helped destroy the fabric of society.

~~~
meddlepal
Just because something has changed in a way you disagree with does not mean it
is destroying the "fabric of society."

~~~
adamnemecek
It's hard to defend fb right now.

------
_ZeD_
Uff... It's in London... When will they move to europe?

