“Evolving Erlang into a modern statically typed programming language” | Hacker News Reader

“Evolving Erlang into a modern statically typed programming language”

web.facebook.com

140 pointslobo_tuerto42 comments

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

They don't mention how, but this is from the job description:

"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."

It sounds like Elixir ;)

Elixir isn’t any more statically typed than Erlang? More modern in many ways, yes, but something like the goals of Typescript over JS are quite different.

Right, Elixir has hints rather than being truly statically typed.

Elixir's hints are identical to erlang's hints, they are just prettier and easier.

However, if you use structs extensively in elixir, with a good code editor language server, it is basically easy to eliminate most typing errors if you get into the habit of typespeccing everything (not hard with vscode)

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.

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.

akka typed is now a thing and it works reasonable well. Though, imo, the actor pattern will always be at odds with statically typed functional programming.

Wow, gleam looks incredible. I love the syntax. Thanks so much for sticking to just double quotes!!!

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

https://codesync.global/media/purescript-on-the-beam-typed-o...

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.

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.

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.

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.

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

And ReasonML. Not a fork exactly, but still.

Erlang already has dialyzer. Are they making another dialyzer?

Dialyzer is absolutely terrible though. I know of no modern, widely used programming tool that has worse error messages. And showing error messages is its only purpose.

It'll tell you there's a problem in function x and actually the problem is 4 functions down the stack. It's nuts, it's shit.

I agree, I've had nothing but trouble with it.

Just the other day, I don't know if serious or not, I read the Phoenix framework's author say I solve 100% of my dialyzer issues by not using dialyzer on Slack.

Funny thing is, I agree that the error messages are terrible, but it catches legitimate bugs sometimes.

I've seen at least a few dozen bugs caught in development over the last few years caught by Dialyzer.

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.

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.

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?

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.

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.

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

http://elchemy.neontree.pl/new

In this case does typescript fit into modern static type system?

Wait does Erlang not have type soundness?

erlang is typed like python is typed. dynamic strong types. it has a static analyzer that will catch mistakes if you add the appropriate type annotations, however.

Huh. TIL. To be honest I always associated functional programming with sound type inference, a. la. Hindley-Milner. (my Haskell background is leaking). Would you happen to know the rationale behind it being unsound?

Hot code reloading and message passing across networks is just easier without it. I can take any erlang term (including lambdas), pickle it, write down the bytes, put it on a carrier pigeon, unpickle it on the other side and it will become the corresponding term on the other side.

Compared with the type checker in Haskell elm rust, dialyzer isn’t that good, we tried it two or three years ago in our project, I wouldn’t even call it useful.

It's more useful with a code editor that runs it all the time and subtly encourages you to write specs.

If this was true, i suspect theirs would be better. Dialyzer doesn't seem very interesting and facebook has a good track record with making modern libraries and implementations.

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

This is currently a matter of legal debate, but I don't think platforms can be held accountable for (most of) the actions of their users. A large part of what would be considered "destroying the fabric of society" - fake news, vitriol, intellectual sophistry, racism, sexism, hatred, etc. - predates Facebook. People have been nasty to each other since time immemorial - a better interpretation is that online dialogue, once the rarefied purview of a select group of well-educated academics and students, has caught up to offline dialogue, rather than deteriorated it.

Algorithmic feed curation has added an element of insularity, but people have always formed communities around what they think and care about. Failures to educate, to inculcate critical thinking, to distinguish between truth and falsehood - these are not the shortcomings of social media not its responsibility to fix, but rather the fault of broader educational and corporate systems that prioritized vocational knowledge over inquiry and examination. We brought our own cudgels - social media is simply another area to bludgeon each other to death.

Facebook can and should be held responsible only insofar as it has directly and with intent manipulated information - I don't think this has happened so far. Attempts to try and make Facebook fix what other systems were supposed to do are examples of first-order thinking - it's more effective to improve schools and colleges, offer opportunities for socioeconomic mobility, and reduce costs of living so that people can be healthier, smarter and more capable, so that they are less likely to begrudge offline or online.

> This is currently a matter of legal debate, but I don't think platforms can be held accountable for (most of) the actions of their users.

it's not a legal argument being discussed. facebook certainly enables the actions of its users, even encouraging users via the site's features and suggestive behavior that emotionally attaches them to using the site. facebook, and basically every other social media platform, seek to "hack" the emotional state of their users to keep them coming back.

Don't believe the hype. Facebook isn't influential enough to destroy the fabric of society. Think critically on this as you walk around the streets and talk to people. Don't just believe what someone at the NY Times tells you. If you hang out with NY Times journalists, you'll see they aren't some special species from outer space embued with magic insights that we don't have.

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

It's hard to defend fb right now.

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

Reply on news.ycombinator.com