10 ms·

Lumen – Elixir and Erlang in the Browser

264 points by lawik 7y ago

evilduck 7y ago
This won't be hard to search for at all. https://lumen.laravel.com/ https://lumen.laravel.com/
- dqv 7y ago
  Not sure who came up with it first, but there's also Laravel Elixir and Laravel Mix which caused some confusion for me when I first heard about Elixir but didn't know it was in the Erlang ecosystem.
  - bitwalker 7y ago
    There is also a Python library called Elixir - naming is hard.
    - conradfr 7y ago
      And a cryptocurrency, which makes for some fun questions sometimes on the elixir (lang) subreddit.
      - mpolsz 7y ago
        And in Poland there is interbank money transfer system called elixir so good luck finding job with elixir (lang) in description.
- lawik 7y ago
  Haha! Oh dear.. I think adding "elixir" to any search is pretty much mandatory. Phoenix, Nerves, Scenic. All need some qualifiers. Ecto might stand on its own.
- bcardarella 7y ago
  If we're going to limit project names in that way we might as well randomly choose letters
  - kerkeslager 7y ago
    It's not that hard. If you can't put 10 minutes effort into choosing a unique, searchable name for your project, what other corners did you cut? It's not a dealbreaker, but it's certainly a red flag.
    - loceng 7y ago
      Not really. It's called branding and because's limited words that naturally have meaning - and the best words are likely to be coopted for projects in similar fields - then it's not difficult for people to search "lumen elixir". Likewise if the site you're on is contextual to Elixir then just searching "lumen" will find the result you're looking for.
      - kerkeslager 7y ago
        > It's called branding and because's limited words that naturally have meaning - and the best words are likely to be coopted for projects in similar fields "best" based on what criteria? Searchability is certainly a factor, no? Branding is pretty useless if people can't find your product. > then it's not difficult for people to search "lumen elixir". Likewise if the site you're on is contextual to Elixir then just searching "lumen" will find the result you're looking for. Right... until someone else creates another Elixir project called Lumen. I think at some point you have to agree that naming collisions are a problem. The question isn't whether naming collisions are a problem, it's how far we want to subdivide fields before we consider collision to be a problem. I'd argue that you're drastically underestimating this effect: having to type "Elixir" is definitely going to prevent some people from finding this project. For example, if I'm working with Elixir, and I need to do some frontend work, and someone on the internet suggests Lumen: I'll search "lumen", find the PHP framework, and probably guess that the person on the internet didn't really understand what I was trying to do, which is not an unreasonable guess given the widely-varying quality of answers from randos on the internet. Sure, I could search "lumen elixir", but how would I know to do that if I didn't already know what it was? Contrast this with other ways of measuring the value of a name. Lumen is a word related to BEAM? Why is that important? Sounds cool? Again, why is that important? Pronounceable/memorable? Okay, but actually there are thousands of words that are unused, that are both those things. You can't trot out "it's called branding" as if that proves any of these things are important: highly successful brands like "Prozac" or "Kleenex" or "Clorox" show that even being a real word isn't important.
- fxleach 7y ago
  Yup. I've used Lumen a couple times over the past few years. Not sure why you would start a new project with that name, it's already well known and easily searchable.
  - prophesi 7y ago
    Not sure why the OP's message was flagged, as it was a totally valid criticism... But yeah, I just started a Lumen project last night for a quick API behind OAuth2. I sometimes have to append "php" or "laravel" to my queries, but that's to be expected considering I don't use Google. I'm a big fan of Elixir and think Lumen's Elixir -> WebAssembly will be awesome, but I do wish they used another magic potion related name for it.
  - dang 7y ago
    There have been many Lumens. Scott's and my hashmap-based Lisp was called that years earlier (https://news.ycombinator.com/item?id=17962433 https://news.ycombinator.com/item?id=17962433). When I contacted the dev of a previous project to ask if he minded us using the name, he replied that there were so many that it didn't matter. Lumens come and go.
- dasil003 7y ago
  Better than Go!
  - rhlsthrm 7y ago
    Golang
    - dasil003 7y ago
      Yes, I'm familiar with the hack that the community is expected to use every time they name the language in a searchable context. No better than prepending Elixir on a search if you ask me.
fraktl 7y ago
I clicked because I thought it's about Laravel's Lumen - turned out it wasn't, that immediately made me CTRL + W. IMO, bad name choice at this stage :/
- 1f97 7y ago
  i mean, it does mention Elixir and Erlang though...
  - fraktl 7y ago
    It does but hey, I'm just a mere mortal forced to use the internet for work so I don't always read the whole sentence or title..
- bnt 7y ago
  Why? Just because Laravel came first and made an abandomware project?
  - fraktl 7y ago
    Because I use Laravel and Lumen every day. My comment doesn't mean "Go change the name because some other project took it". I'm also very sorry you felt attacked immediately and had to declare Laravel's Lumen an abandonware project. However, I am surprised no one bashed the language it's written in (but the night is still young) :) I understand that there's hundreds of millions of programmers and that we're bound to name-clash, it's just the nature of limited data-set that vocabulary represents. I don't offer a solution here, but this just goes to show how people think. And if people think like that, search engines might have a few thoughts on their own when it comes to words "Lumen" and "Illuminate". Have an excellent and productive day.
  - Elidrake24 7y ago
    Abandonware? It's still actively supported/updated with each major Laravel release. We use it in our shop for some quick microservices.
lawik 7y ago
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 7y ago
  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 7y ago
    > 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.
    - deleted 7y ago
      [deleted]
  - pjmlp 7y ago
    I bet that in about 5 years time the browser plugins would have had their revenge, unless the browser vendors pull the plug on WebAssembly.
    - sitkack 7y ago
      Wasm is the most transformative tech to come along since Linux.
hopia 7y ago
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 7y ago
  > 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.
  - mstade 7y ago
    This sounds like an interesting experiment, do you have a repo or anything one could follow?
    - bcardarella 7y ago
      https://github.com/lumen/db_mon_demo https://github.com/lumen/db_mon_demo There is a db_mon-esque implementation within the source and ultimately this is where the demo will live but for now (and the purposes of that demo at ElixirConf) I went in a different direction
  - hopia 7y ago
    Oh wow sounds like a pretty fundamental overhaul of the current DOM model. Then again, various virtual DOM diff implementations have shown they can improve working with the DOM a lot.
prostaff 7y ago
Cool Site! www.aeroworxglobal.com
johnmarcus 7y ago
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 7y ago
  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.
- bitwalker 7y ago
  That’s not how WebAssembly works, at all, it is handled directly by browser JIT compilers.
h91wka 7y ago
Interesting project... I wonder does it have same kind of processes preemption based on reductions like BEAM?
- lawik 7y ago
  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 7y ago
    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.
- xtian 7y ago
  Yes - preemptive multitasking is core to the BEAM process model.
- bitwalker 7y ago
  Yes, Lumen has a scheduler and does preemption the same way the BEAM does.
derefr 7y ago
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?
- lawik 7y ago
  I think you can get more info from the video linked there. I don't recall the details but if it isn't Web Workers there might be something in Wasm. I'm pretty sure it's intended to be able to run multiple schedulers. But I'm not the one building it so not sure.
- bitwalker 7y ago
  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 7y ago
    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 7y ago
      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.
waynesonfire 7y ago
this is fantastic work. thank you and keep up the great work! The day JS becomes irrelevant will be joyous.
- deleted 7y ago
  [deleted]
Quarrelsome 7y ago
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_nightmare_before_blazor/faztnnk/ https://www.reddit.com/r/csharp/comments/ea5dnb/the_nightmar...
- learc83 7y ago
  That guy is using server side blazer which doesn't use wasm. And his experiences aren't normal.
  - sansnomme 7y ago
    But Lumen, if combined with Phoenix LiveView, is basically Blazor.
    - toolz 7y ago
      specifically which part of the comment touched on an issue you would expect to translate to lumen?
  - Quarrelsome 7y ago
    or just ignore the warning. Go for it, deploy it to production.
- toolz 7y ago
  this is just FUD spreading. Having a bad experience with Blazor doesn't translate to anything on the BEAM.
darkstar999 7y ago
Unfortunate name clash https://lumen.laravel.com/ https://lumen.laravel.com/
- pull_my_finger 7y ago
  Doubly unfortunate https://github.com/sctb/lumen https://github.com/sctb/lumen
  - dang 7y ago
    There have been many. https://news.ycombinator.com/item?id=22140357 https://news.ycombinator.com/item?id=22140357
AbraKdabra 7y ago
Uh, Lumen is already in use by the Laravel team for their micro-framework, maybe they're in time for a name change?
- aikah 7y ago
  Unless Laravel team trademarked the name and are ready to go to court to defend it, I don't see why.
- seanclayton 7y ago
  Elixir has had Mix since 2012, but Laravel made Laravel Mix in 2016 and hasn't changed it.
elcritch 7y ago
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 7y ago
  There is also nerves which specifically targets embedded applications: https://nerves-project.org/ https://nerves-project.org/
- lawik 7y ago
  Something like this thing? https://github.com/wasm3/wasm3 https://github.com/wasm3/wasm3 The sample I tried in this post is only an Erlang interpreter. The whole compile chain is not quite ready from what I gather. It should be feasible at later point. I don't see why not.
- bcardarella 7y ago
  microprocessor/embedded systems is a compilation target after the initial browser implementation. We're very aware of how awesome it would be to have the Erlang programming model without having to require an OS
- deleted 7y ago
  [deleted]
pmarreck 7y ago
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".

264 points by lawik 7y ago

evilduck 7y ago

This won't be hard to search for at all. https://lumen.laravel.com/ https://lumen.laravel.com/

dqv 7y ago
Not sure who came up with it first, but there's also Laravel Elixir and Laravel Mix which caused some confusion for me when I first heard about Elixir but didn't know it was in the Erlang ecosystem.
- bitwalker 7y ago
  There is also a Python library called Elixir - naming is hard.
  - conradfr 7y ago
    And a cryptocurrency, which makes for some fun questions sometimes on the elixir (lang) subreddit.
    - mpolsz 7y ago
      And in Poland there is interbank money transfer system called elixir so good luck finding job with elixir (lang) in description.
lawik 7y ago
Haha! Oh dear.. I think adding "elixir" to any search is pretty much mandatory. Phoenix, Nerves, Scenic. All need some qualifiers. Ecto might stand on its own.
bcardarella 7y ago
If we're going to limit project names in that way we might as well randomly choose letters
- kerkeslager 7y ago
  It's not that hard. If you can't put 10 minutes effort into choosing a unique, searchable name for your project, what other corners did you cut? It's not a dealbreaker, but it's certainly a red flag.
  - loceng 7y ago
    Not really. It's called branding and because's limited words that naturally have meaning - and the best words are likely to be coopted for projects in similar fields - then it's not difficult for people to search "lumen elixir". Likewise if the site you're on is contextual to Elixir then just searching "lumen" will find the result you're looking for.
    - kerkeslager 7y ago
      > It's called branding and because's limited words that naturally have meaning - and the best words are likely to be coopted for projects in similar fields "best" based on what criteria? Searchability is certainly a factor, no? Branding is pretty useless if people can't find your product. > then it's not difficult for people to search "lumen elixir". Likewise if the site you're on is contextual to Elixir then just searching "lumen" will find the result you're looking for. Right... until someone else creates another Elixir project called Lumen. I think at some point you have to agree that naming collisions are a problem. The question isn't whether naming collisions are a problem, it's how far we want to subdivide fields before we consider collision to be a problem. I'd argue that you're drastically underestimating this effect: having to type "Elixir" is definitely going to prevent some people from finding this project. For example, if I'm working with Elixir, and I need to do some frontend work, and someone on the internet suggests Lumen: I'll search "lumen", find the PHP framework, and probably guess that the person on the internet didn't really understand what I was trying to do, which is not an unreasonable guess given the widely-varying quality of answers from randos on the internet. Sure, I could search "lumen elixir", but how would I know to do that if I didn't already know what it was? Contrast this with other ways of measuring the value of a name. Lumen is a word related to BEAM? Why is that important? Sounds cool? Again, why is that important? Pronounceable/memorable? Okay, but actually there are thousands of words that are unused, that are both those things. You can't trot out "it's called branding" as if that proves any of these things are important: highly successful brands like "Prozac" or "Kleenex" or "Clorox" show that even being a real word isn't important.
fxleach 7y ago
Yup. I've used Lumen a couple times over the past few years. Not sure why you would start a new project with that name, it's already well known and easily searchable.
- prophesi 7y ago
  Not sure why the OP's message was flagged, as it was a totally valid criticism... But yeah, I just started a Lumen project last night for a quick API behind OAuth2. I sometimes have to append "php" or "laravel" to my queries, but that's to be expected considering I don't use Google. I'm a big fan of Elixir and think Lumen's Elixir -> WebAssembly will be awesome, but I do wish they used another magic potion related name for it.
- dang 7y ago
  There have been many Lumens. Scott's and my hashmap-based Lisp was called that years earlier (https://news.ycombinator.com/item?id=17962433 https://news.ycombinator.com/item?id=17962433). When I contacted the dev of a previous project to ask if he minded us using the name, he replied that there were so many that it didn't matter. Lumens come and go.
dasil003 7y ago
Better than Go!
- rhlsthrm 7y ago
  Golang
  - dasil003 7y ago
    Yes, I'm familiar with the hack that the community is expected to use every time they name the language in a searchable context. No better than prepending Elixir on a search if you ask me.

fraktl 7y ago

I clicked because I thought it's about Laravel's Lumen - turned out it wasn't, that immediately made me CTRL + W. IMO, bad name choice at this stage :/

1f97 7y ago
i mean, it does mention Elixir and Erlang though...
- fraktl 7y ago
  It does but hey, I'm just a mere mortal forced to use the internet for work so I don't always read the whole sentence or title..
bnt 7y ago
Why? Just because Laravel came first and made an abandomware project?
- fraktl 7y ago
  Because I use Laravel and Lumen every day. My comment doesn't mean "Go change the name because some other project took it". I'm also very sorry you felt attacked immediately and had to declare Laravel's Lumen an abandonware project. However, I am surprised no one bashed the language it's written in (but the night is still young) :) I understand that there's hundreds of millions of programmers and that we're bound to name-clash, it's just the nature of limited data-set that vocabulary represents. I don't offer a solution here, but this just goes to show how people think. And if people think like that, search engines might have a few thoughts on their own when it comes to words "Lumen" and "Illuminate". Have an excellent and productive day.
- Elidrake24 7y ago
  Abandonware? It's still actively supported/updated with each major Laravel release. We use it in our shop for some quick microservices.

lawik 7y ago

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 7y ago
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 7y ago
  > 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.
  - deleted 7y ago
    [deleted]
- pjmlp 7y ago
  I bet that in about 5 years time the browser plugins would have had their revenge, unless the browser vendors pull the plug on WebAssembly.
  - sitkack 7y ago
    Wasm is the most transformative tech to come along since Linux.

hopia 7y ago

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 7y ago
> 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.
- mstade 7y ago
  This sounds like an interesting experiment, do you have a repo or anything one could follow?
  - bcardarella 7y ago
    https://github.com/lumen/db_mon_demo https://github.com/lumen/db_mon_demo There is a db_mon-esque implementation within the source and ultimately this is where the demo will live but for now (and the purposes of that demo at ElixirConf) I went in a different direction
- hopia 7y ago
  Oh wow sounds like a pretty fundamental overhaul of the current DOM model. Then again, various virtual DOM diff implementations have shown they can improve working with the DOM a lot.

prostaff 7y ago

Cool Site! www.aeroworxglobal.com

johnmarcus 7y ago

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 7y ago
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.
bitwalker 7y ago
That’s not how WebAssembly works, at all, it is handled directly by browser JIT compilers.

h91wka 7y ago

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

lawik 7y ago
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 7y ago
  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.
xtian 7y ago
Yes - preemptive multitasking is core to the BEAM process model.
bitwalker 7y ago
Yes, Lumen has a scheduler and does preemption the same way the BEAM does.

derefr 7y ago

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?

lawik 7y ago
I think you can get more info from the video linked there. I don't recall the details but if it isn't Web Workers there might be something in Wasm. I'm pretty sure it's intended to be able to run multiple schedulers. But I'm not the one building it so not sure.
bitwalker 7y ago
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 7y ago
  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 7y ago
    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.

waynesonfire 7y ago

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

deleted 7y ago
[deleted]

Quarrelsome 7y ago

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_nightmare_before_blazor/faztnnk/ https://www.reddit.com/r/csharp/comments/ea5dnb/the_nightmar...

learc83 7y ago
That guy is using server side blazer which doesn't use wasm. And his experiences aren't normal.
- sansnomme 7y ago
  But Lumen, if combined with Phoenix LiveView, is basically Blazor.
  - toolz 7y ago
    specifically which part of the comment touched on an issue you would expect to translate to lumen?
- Quarrelsome 7y ago
  or just ignore the warning. Go for it, deploy it to production.
toolz 7y ago
this is just FUD spreading. Having a bad experience with Blazor doesn't translate to anything on the BEAM.

darkstar999 7y ago

Unfortunate name clash https://lumen.laravel.com/ https://lumen.laravel.com/

pull_my_finger 7y ago
Doubly unfortunate https://github.com/sctb/lumen https://github.com/sctb/lumen
- dang 7y ago
  There have been many. https://news.ycombinator.com/item?id=22140357 https://news.ycombinator.com/item?id=22140357

AbraKdabra 7y ago

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

aikah 7y ago
Unless Laravel team trademarked the name and are ready to go to court to defend it, I don't see why.
seanclayton 7y ago
Elixir has had Mix since 2012, but Laravel made Laravel Mix in 2016 and hasn't changed it.

elcritch 7y ago

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 7y ago
There is also nerves which specifically targets embedded applications: https://nerves-project.org/ https://nerves-project.org/
lawik 7y ago
Something like this thing? https://github.com/wasm3/wasm3 https://github.com/wasm3/wasm3 The sample I tried in this post is only an Erlang interpreter. The whole compile chain is not quite ready from what I gather. It should be feasible at later point. I don't see why not.
bcardarella 7y ago
microprocessor/embedded systems is a compilation target after the initial browser implementation. We're very aware of how awesome it would be to have the Erlang programming model without having to require an OS
deleted 7y ago
[deleted]

pmarreck 7y ago

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".