Introducing MLFE: ML-Flavoured Erlang | Hacker News Reader

Introducing MLFE: ML-Flavoured Erlang

noisycode.com

137 pointsingve20 comments

I think it could be a mistake to put this out there when it's still so early. The features are not there(0) yet and it's likely to be overhauled a lot.

It's an extremely exciting proposition and I both hope and think it will become a force to be reckoned with in the erlang community.

(The name is currently not well accepted on the erlang mailing list, by the way, but is yet to be commented on by j14159)

0 - https://github.com/j14159/mlfe#whats-missing

It was rough but it worked out for Rust.

BTW, there have been at least two other ML on BEAM attempts before. One experimental in the open and another unpublished one.

Damn, I kind of wish Elixir had gone with a high quality type system... dialyzer is just so limited. Glad to see some experimentation on this front. Any idea whether it would be possible to interface with existing Erlang libraries?

If you're interested in a much richer type system, but also like the actor model, check out Pony (http://www.ponylang.org/), which has some pretty seriously great goals.

That said, I think the theory was that dialyzer's success typing was the most industrially pragmatically acceptable type system available at the time -- the one that you could actually get people to use -- and given all that, it's not half bad. Certainly better than nothing.

Yeah, Pony looks very cool. Unfortunately I don't think I could convince work to use it at this early stage, but I'm looking forward to see how it develops. Huge bonus points for being based on soundness proofs from the very start.

Yeah, Dialyzer is better than nothing. I guess I get saddened by the lack of parametric polymorphism due to being spoiled by Rust and Haskell, and have been sceptical due to noticing that type inference sometimes falls back to the top type without me realizing. Kind of hard to trust a type system to have your back after that.

Yeah, I gave up relying on type inferencing; at minimum I add type annotations to every exported function in a module, and every function that calls out to an external resource (i.e., a function that reads from an external database, I'd declare what is returned).

an ML on the erlang vm seems very interesting. static typing woot!

(does one pronounce MLFE as "milfy"?)

I hope so.

I thought the whole point of not statically typing erlang was because upgrades are done on live systems.

I used to think so as well, but not any more. Any non-trivial service needs persistence, so it must checkpoint its state periodically. Also, the service is distributed to prevent a server from being a single point of failure. In this age of lightweight containers and microservices, restarting the program on an upgrade seems to me a perfectly reasonable alternative.

How do you think statically typing Erlang make in-place upgrades easier/possible?

You can also do live updates on strong typed systems.

The only thing needed is support for dynamic loading and unloading of modules.

The biggest problem, which dynamic systems also suffer from, is how to smoothly perform the updates with inflight requests.

Yeah, but what happens when the api surface of one of the modules changes? Erlang's dynamic typing, combined with its philosophy of treating crashed processes as normal, means that you can deploy the upgraded module on multiple machines without any kind of rigorous synchronization. If you want to do the same with a statically typed system you have to be able to handle the case of one module not being well typed against another. You might accomplish this by implementing transactional upgrades, but that's likely to cause a hiccup across the whole cluster, or else you could essentially define dynamically typed runtime semantics, which would lose a lot of the value of static typing.

You do it like in Mesa/Cedar for example.

Unload all the modules and reload them again.

In Cedar, or ETHZ Oberon for that matter, all executables are dynamically loaded and can be either used by other modules or exposed to the user as commands.

Loading a new version means unloading the module and its dependencies.

When it gets re-loaded it has a the new interface available.

Of course, there is the issue to solve any possible compilation errors before the module can be loaded again.

A similar approach can be done in Java and .NET via classloaders and app domains respectively.

Repository: https://github.com/j14159/mlfe

ML on BEAM - a combination from dream! If this gets any traction, I'm sold.

Possibly also relevant: http://www.ponylang.org/

Pony is really cool but does not run on the Erlang VM which is pretty battle tested at this point.

Agreed. I just suspect it has similar goals (I've heard it described as "statically typed Erlang" in the past, and addresses concurrency at the type level in ways I suspect MLFE doesn't).

The idea of being able to mix MLFE, LFE and raw Erlang is an exciting proposition. Correctness, genericity, and being statically typed, I could see compiling MLFE into Rust and running it inside BEAM. So much gradual goodness.

Reply on news.ycombinator.com