Hacker News Reader

Comment by sergiomattei | Hacker News Reader

I don’t think Firefly gets rid of the OTP.

OTP is a programming library/paradigm that doesn't work without the ability to create extremely lightweight threads, which is what the BEAM provides.

Apparently it has feature parity with the BEAM, but lacks support for NIFs

https://github.com/GetFirefly/firefly#runtime

It doesn't currently, but you are correct that the goal is to maintain feature parity with the BEAM (with explicit caveats to that, namely hot code loading). There actually is support for NIFs, just not via the erl_nif interface that NIFs use today, support for that will arrive eventually.

BEAM isn't the only runtime possible with green threads. OTP is just the libraries.

Lots of people have written alternatives to BEAM. The only problem they run into is that BEAM is very good, and would be tough to beat. I was an admirer of Erlang on Xen: https://github.com/cloudozer/ling

I don't understand, isn't the BEAM just a software runtime that provides a lightweight thread implementation that OTP can use? Why couldn't they implement an alternative that runs on WASI?

I agree that Elixir without OTP becomes much less useful, but there could be some changes to the language to enable in-process state changes so that you wouldn't be limited to a single process and the immutability restrictions that would make that very difficult to do anything useful with. I'm sure they thought of this problem and have a solution in some form.

Correct, the BEAM is just one implementation of the runtime, there can (and have) been others. Firefly aims to be as close to the BEAM semantics as possible, but there will naturally be some differences as we're taking a different approach with compilation, with some benefits as a result, but naturally there are also tradeoffs.

Reply on news.ycombinator.com