
Introducing MLFE: ML-Flavoured Erlang - ingve
http://noisycode.com/blog/2016/06/27/introducing-mlfe/
======
59nadir
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](https://github.com/j14159/mlfe#whats-missing)

~~~
cm3
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.

------
bjz_
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?

~~~
felixgallo
If you're interested in a much richer type system, but also like the actor
model, check out Pony ([http://www.ponylang.org/](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.

~~~
bjz_
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.

~~~
lostcolony
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).

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

(does one pronounce MLFE as "milfy"?)

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

~~~
pjmlp
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.

~~~
adrusi
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.

~~~
pjmlp
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.

------
brudgers
Repository: [https://github.com/j14159/mlfe](https://github.com/j14159/mlfe)

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

------
Jweb_Guru
Possibly also relevant: [http://www.ponylang.org/](http://www.ponylang.org/)

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

~~~
Jweb_Guru
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).

~~~
sitkack
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.

