Lumen: An alternative BEAM implementation, designed for WebAssembly

Re:Lumen: An alternative BEAM implementation, designed for W... by pron on Sunday September 01, 2019 @11:04AM (#20852640)

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?

[ Parent | on HN ]

Re:Lumen: An alternative BEAM implementation, designed for W... by bcardarella on Sunday September 01, 2019 @11:06AM (#20852660)

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.

[ Parent | on HN ]

Re:Lumen: An alternative BEAM implementation, designed for W... by pron on Sunday September 01, 2019 @11:07AM (#20852665)

Thanks!

[ Parent | on HN ]

Re:Lumen: An alternative BEAM implementation, designed for W... by blatyo on Monday September 02, 2019 @01:02AM (#20856864)

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.

[ Parent | on HN ]

Re:Lumen: An alternative BEAM implementation, designed for W... by pron on Monday September 02, 2019 @06:57AM (#20858239)

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

[ Parent | on HN ]