Hacker News new | past | comments | ask | show | jobs | submit login

Hi I'm Brian, one of the member of the Lumen team. I'll try to address some of the questions I've seen in this thread:

1. Why?

We've seen every growing complexity in building, maintaining, extending, and debugging client side applications. There are several reasons why this is but in our opinion how JS handles concurrency (the Event Loop) is a primary factor. Erlang's concurrency model is superior (also our opinion) in how a developer reasons about concurrency. We want to bring this power to building client side web apps.

2. I'm afraid of [it] being over-engineered, and hard to contribute to.

Lumen itself is just the beginning of what we hope is an eco system of tooling and potential framework pieces for building web applications. When building Elixir or Erlang applications developers are not expected to be contributing back to the BEAM or to even understand how it works. Lumen will be in a similar position. When we finally get to `mix install lumen` you will likely only be including Lumen as a dependency in your apps. Higher level functionality will emerge that use Lumen to compile to WASM. However, we highly encourage people with experience in Rust, compiler design, runtime design, Erlang/BEAM, or just general curiosity to get involved in developing Lumen :)

3. even Chris McCord said that in all his years of consulting, he's only gotten a handful of requests for these types of apps

Chris works here at DockYard, and this is because we don't put Chris on our PWA/SPA projects. While there is an obvious demand for LiveView to relieve people from needing a client side framework there are most definitely many clients and plenty of projects where client side apps make sense.

4.an alternative BEAM implementation that behaves like a regular VM rather than BEAM?

Not entirely, although some concessions need to be made when working within the security model of the web. I would very much like it is the browser vendors would give up the argument that Web Workers fulfill the threading requirement of WASM as I personally feel that is disingenuous. I'm hoping that as Lumen develops and (hopefully) picks up steam/influence we can start to see some of these features land for real.

5. Due to size issues I probably wouldn't want to ship the entire BEAM to my users

Correct, and we aren't advocating for this. Lumen is currently in a very early stage of development and we haven't even implemented any compilation optimizations like dead code elimination. There are many other WASM specific optimizations that could cut the footprint size by 50% and this is before we even gzip, which WASM is designed to respond well to despite being a binary.

I'll keep a running list of responses in this thread if more questions come up.

Something that I forgot to include in the keynote is that we are very adamant that Lumen not be viewed as competing compiler/runtime for the BEAM. We don't want that responsibility and we most certainly don't want any drama that could come about from the perception that we are trying to fork a community. We are 100% committed to the BEAM being the primary implementation for Erlang/Elixir and that we will follow as we target platforms that are currently unsupported by the BEAM. I can probably spell this out in the README at some point but I would considered Lumen broken if it ever decided to deviate from BEAM. Code that runs in Lumen should always run on the BEAM.

I'd like to also add that Lumen as a concept for bringing the functionality and development environment of the BEAM to building web apps is very much still an experiment. We are still months away from having something that people can develop with, let alone proving that this is a viable idea. We think it is and we hope as Lumen continues to be developed that our concepts/ideas begin to land.

On another note, it seems this tooling could also be used for native BEAM as well. Perhaps C/C++ NIF’s compiled to wasm for extra safety. Maybe as an alternative to HiPE as it appears to be somewhat dead, and using wasm jit’s might make sense. Exciting experiment!

Compiling to native in some form like WASI is in our roadmap. We are shying away from promoting this too much at the moment (but I don't want to be dodgy about it) as we want the current focus to be on Web Assembly. We know there will be interest an excitement about the potential of building native Erlang apps without the complexity of an underlying OS, but as it stands we cannot spread our resources too thin so we've opted to tackle WASM first then "go native".

Excellent to hear. It makes sense to keep your focus on the front-end, though the general idea of a WASM style "native" code would be very interesting for many of us as you say. There's one group running BEAM on bare metal using just an RTOS [1] but even just WASM code for hot paths would be handy instead of writing NIFs. It'll be fun to see how the project goes, best of luck!

1: https://www.grisp.org/

I would love to know a deep comparison of Elixir(LiveView or other libraries) Vs AngularJS or VueJS or ReactJS for building modern progressive SPA and how much productivity is achieved.

LiveView isn't meant to be a replacement for Angular/Vue/React. It is meant to address the many companies/projects that were once doing some light client side functionality with jQuery or prototype and have since gone full framework and are now finding themselves with a much longer time to implement what was once simple. The overhead that frameworks impose are meant to manage complexity but if the interactions are simple then that overhead is a liability.

Some people also just don't like JS so there is that.

Thanks for reply.

I can't give a deep comparison since I haven't done anything too deep with LiveView (yet!) but I would encourage you to watch the keynotes on LiveView[1][2] if you're really interested. I have spent the last few years working with React / Redux on a big SPA and I believe the entire thing could easily be supported by LiveView; we don't do anything fancy, its basically just a bunch of CRUD based pages.

Another shallow comparison is that LiveView isn't meant to compete with modern progressive SPAs. While it can update the DOM with data from the server and is very good at doing that, it has limitations such as no offline support. Chris (the speaker in the videos) also notes that if your clients require very good latency or a very complex UI (think Google Sheets) then a JS framework will probably better suit your needs. However, if you're building out a majority of websites (CRUD type pages) that a lot of us web developers do, my personal opinion is that LiveView will be able to everything needed.

[1] Announcing LiveView @ ElixirConf 2018 - https://www.youtube.com/watch?v=Z2DU0qLfPIY [2] LiveView Update @ ElixirConf 2019 - https://www.youtube.com/watch?v=XhNv1ikZNLs

if you want a shallow comparison. I'm a senior dev, and I hired a junior who went to a bootcamp to solve the problem of "bootstrap a react project" for me (honestly, I'm too old to figure out how to do that -- once the project is up I'm pretty productive in react). This took him about a week. I also gave him an instruction to "bootstrap a phoenix liveview" for me, and even though he's less good at elixir (which he learned on the job) than JS, he got something up and running in two days. He then later taught me how to stand up phoenix liveview, which amounted to "pointing me to the docs" and I build a phoenix liveview app from the docs (normally i have to watch a video).

I could be missing something important about WASM (or BEAM), but why are you compiling to WASM rather than JS? Seems to me that's losing on most fronts: performance, effort and code size. WASM is a reasonable compilation target for C; not so much for untyped languages with a GC, while JS is a decent compilation target exactly for such languages. What's the gain with WASM?

I think you're looking at this as a transpiler, it is not. We are implementing a runtime which most definitely wouldn't be performant or of a reasonable footprint size in JS.

Beating V8's GC and JIT would be extremely hard given they're of pretty good quality, and I don't even know if you could write a JIT in WASM (can you?). Do you think implementing an interpreter and a GC in WASM could be faster/smaller than exploiting one of the best JITs out there and easier/smaller than taking advantage of a built-in GC? Moreover, you seem to be giving up on dynamic code loading in exchange for worse performance.

I'm not trying to challenge you, I just work on VMs and I don't understand the thought process behind such an unusual decision, but that could be because I don't know much about WASM. What am I missing?

This question is better fielded by Paul, Luke, or Hans. I gave them the week off after the conference so I cannot promise they'll reply here on HN. If you want to contact me over email (brian at dockyard.com) I can try to have them follow up on this.


This isn't a complete answer to you're question, but one note. They aren't building an interpreter in wasm. They are compiling elixir to native wasm. Elixir code wouldn't be shipped to the client.

Of course, but compiling to JS seems like it could be faster, smaller and easier, and support more features.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact