
Lumen – Elixir and Erlang in the Browser - lawik
https://underjord.io/lumen-elixir-in-the-browser.html
======
lawik
What I find the most interesting about it is that it doesn't try to rework the
BEAM to fit in the browser but rather does the much more ambitious work of
trying to compile something fairly optimized that won't bloat the frontend.

~~~
danShumway
Agreed, I was happy to see this.

I like Javascript, a lot, but I would very happily see a future where people
have more choices about languages to use on the front-end. My only fear was
that everything was going to morph into a kind of Java Applets 2.0, where
everything would just be a giant VM on top of another VM.

For the most part, languages aren't doing that though, they're putting in the
work to do proper integration with "native" browser systems like the DOM/CSS.
I'm optimistic about where language efforts like Rust/Erlang/C#/C are headed,
I think these projects are going to be really good for the web overall.

~~~
bcardarella
> everything would just be a giant VM on top of another VM

this concern is real which is why we didn't just run BEAM c source through a
WASM compiler and call it a day. The implementation here is to optimize
compilation to WASM and avoid as much overhead as possible. We have footprint
requirements for the compiled asset sizes in mind too.

------
derefr
One thing I wasn't able to ascertain from the link: would this run your Erlang
code with the semantics of a single-scheduler BEAM node (i.e. concurrently,
but not in parallel); or does this use Web Workers to have multiple parallel
schedulers?

~~~
bitwalker
Initially we’re not planning to support multiple schedulers via WebWorkers,
but the runtime has support for multiple schedulers generally speaking. Since
the compiler can target other platforms, we didn’t want to artificially limit
all targets due to any particular target limitations. As far as Wasm is
concerned though, once browser support for SharedArrayBuffer returns, then
we’d be looking to take advantage of multiple threads.

~~~
derefr
Then, could a Lumen user do what pre-SMP Erlang did for parallelism, and

1\. run multiple nodes on one machine (i.e. manually create Web Workers each
with their own copy of Lumen); and then

2\. write an erl_dist alternative-carrier protocol driver that uses
worker.postMessage()?

~~~
bitwalker
Sure, I can't imagine any particular reason why that wouldn't work. That said,
we don't have distribution implemented yet, since we are focused on a single
node in the browser initially; so it depends on which comes first -
SharedArrayBuffer being stabilized again in the browsers so we can enable
multiple schedulers, or getting distribution implemented thoroughly enough to
support the approach you mentioned as a workaround.

------
pmarreck
I think this project is a great idea but I think it's overly ambitious to be
reasonably feasible in a near-term timeframe as it's basically talking about
re-implementing 20+ years and thousands of man-hours put into BEAM dev into
the browser.

It's also competing time-wise with simply "compiling Erlang itself to
emscripten/WASM", since computing capability will still scale over time in
speed and bandwidth and memory capacity to the point that simply "being able
to get ALL of Elixir in the browser" will outvalue "being able to run some
subset of Elixir in a single-threaded context only in the browser" (assuming
performance is not an order of magnitude different).

I was just reading another HN article discussing the fact that OLAP is going
away simply because computers have gotten enough memory and databases have
gotten fast enough at querying columnar data stores that it's no longer
necessary to add the "optimization complexity" of OLAP to get reasonable data
analysis performance.

AMD has the Ryzen Threadripper now, 32 cores with 64 threads... If CPU
development continues in that direction, this will be a BIG win for Elixir but
only if it can take advantage of more than one thread.

That all said, I'm sure a naïve recompilation of Erlang BEAM to
emscripten/WASM might not automatically take advantage of those threads
properly out-of-the-box due to the abstraction layer, so there'd also have to
be some work there to massage the scheduler to use "real" threads "on the
metal".

------
hopia
Am I understanding this right that it's actually implementing the actor model
just like Erlang? It seems to have processes and you can send them messages.

The threads seem really lightweight, but how would some typical frontend
benefit from this?

~~~
bcardarella
> how would some typical frontend benefit from this

At ElixirConf I built a simple supervisor DOM tree model. When we are ready to
implement it for real we're going to experiment with mapping the DOM to a
supervisor. Each node being an element. This way events and rendering take
place in each node in the supervisor tree. Rendering would be diff based and
merged its way back up. Events would be captured as messages in the idiomatic
Erlang/Elixir way.

This is all guess work right now and we don't yet know what will be practical
vs what sounds good in theory.

However, we are dedicated to the idea that the programming model of the BEAM
is one that complex client-side applications will benefit from over what
JavaScript current offers.

~~~
lawik
That sounds pretty close to what Scenic does for OpenGL-rendered UI.

Scenic has some interesting properties in that if a specific component has a
code problem and fails/crashes, the supervision tree will bring it back to
life. I'm curious to see what similar things one could do with Lumen for the
web.

Components are already a very popular level of abstraction with Vue and React,
probably others. So maybe there are useful things to bring from Scenic.

~~~
bcardarella
Scenic is one area that I've looked to for inspiration on what a GUI can be
like in Elixir

------
waynesonfire
this is fantastic work. thank you and keep up the great work! The day JS
becomes irrelevant will be joyous.

------
h91wka
Interesting project... I wonder does it have same kind of processes preemption
based on reductions like BEAM?

~~~
lawik
Is that the thing where after a number of reductions by a single process the
BEAM will make sure another process gets its time in the sun? I believe so but
I'm not familiar enough with the internals. They definitely spoke about
reductions in the meeting I half-listened to.

~~~
anthony_doan
Correct. It makes it so for(true) in other languages doesn't hijack the cpu
and strive for the low latency goals of Erlang.

To be fair you can go about it by just filling up a process mail box with tons
of messages.

------
elcritch
I’d love to try using a wasm interpreter to run this on microprocessors! Is
the project at a point that’d be feasible to test?

~~~
rubyn00bie
There is also nerves which specifically targets embedded applications:
[https://nerves-project.org/](https://nerves-project.org/)

------
AbraKdabra
Uh, Lumen is already in use by the Laravel team for their micro-framework,
maybe they're in time for a name change?

~~~
seanclayton
Elixir has had Mix since 2012, but Laravel made Laravel Mix in 2016 and hasn't
changed it.

------
Quarrelsome
Mandatory word of warning [1]. Don't use wasm magic like this in production
until its ready.

[1]
[https://www.reddit.com/r/csharp/comments/ea5dnb/the_nightmar...](https://www.reddit.com/r/csharp/comments/ea5dnb/the_nightmare_before_blazor/faztnnk/)

~~~
learc83
That guy is using server side blazer which doesn't use wasm. And his
experiences aren't normal.

~~~
sansnomme
But Lumen, if combined with Phoenix LiveView, is basically Blazor.

~~~
toolz
specifically which part of the comment touched on an issue you would expect to
translate to lumen?

------
johnmarcus
So you write it in elixer and web assembly converts it to Js that browsers
understand. Cool. Just write it in JS and it will probably be faster.

~~~
lawik
That's not accurate. WebAssembly is a different beast than JS. As far as I've
understood it is executed differently and can do some different things. I
don't see any reason why it couldn't be optimized more than JS either, though
that's bound to take some time considering the amount of tuning that's gone
into JS engines.

More accurately, you write Elixir, it compiles down to Wasm. Wasm is run by
your browser as a more machine-friendly format than JS. It may well be faster.

