7 ms·

Apologies, what is the sell here? Lots of usage instructions & details but why use this vs Beam actual?

zacksiri 4y ago
I may be wrong but, “designed for WebAssembly” might be the key selling point here. I imagine we would be able to write elixir on the frontend with this.
- throwawaymaths 4y ago
  If I were to try to do a straight shot at getting elixir on the frontend I'd just send bytecode up to the frontend and interpret it, either in js or wasm. Erlang bytecode is fairly straightforward, and especially if you stay single threaded you can make a reasonable approximation of the compute model[0]. The hardest parts I imagine would be coming up with an abstraction that lets you manipulate the DOM and test it while staying in the elixir test environment, which is insanely good. I don't see how firefly makes that particular challenge any easier. I feel like the dockyard folks just got rust crazy and decided to do this -- for reasons[1], rust is honestly not the best language to do a BEAM implementation in, which is I think why they pivoted to a compiler [0] except for the fact that a lot of libraries unnecessarily spawn processes. [1] https://www.erlang.org/doc/man/erts_alloc.html https://www.erlang.org/doc/man/erts_alloc.html
  - illiarian 4y ago
    > If I were to try to do a straight shot at getting elixir on the frontend I'd ... use LiveView :)
    - throwawaymaths 4y ago
      Like this proposes eventually obviating the need for things like LiveView.JS, LiveView hooks, etc.
  - yellowapple 4y ago
    > except for the fact that a lot of libraries unnecessarily spawn processes. Well yeah, that's kinda the whole point of Erlang in the first place :)
- bhaney 4y ago
  Pretty much exactly that, yeah. From the README: > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development
- lolinder 4y ago
  Phoenix+LiveView already seems to do this really well—what's the niche for an Elixir SPA?
  - rkangel 4y ago
    I'm a big fan of LiveView, but when you get to a very high degree of interactivity or anything that needs to work well offline or with bad signal quality then LiveView is not the right choice.
    - POiNTx 4y ago
      For very high degree of interactivity I've been working on LiveSvelte which might solve that issue for you. Your other points still stand though. https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
  - victorbjorklund 4y ago
    You can build an app that runs entirely in the browser eliminating the need to have a server and reducing latency. Of course it doesn't make sense for all use cases but for some apps it might make a lot of sense. For example that is how Liveview Desktop works.
manveru 4y ago
See the about section: https://github.com/GetFirefly/firefly#about-firefly https://github.com/GetFirefly/firefly#about-firefly > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development. It is also possible to use Firefly to target other platforms as well, by producing self-contained executables on platforms such as x86.
- rektide 4y ago
  Great! Nice. Very neat possibilities here. I'd be very very interested to hear follow up, on how Firefly does actors. I feel like there's so many potential ways to target wasm, but the high concurrency spirit of Beam has such unique flavor. I'd love to read in & hear that spirit is well preserved.
  - madsbuch 4y ago
    There are details on this also: https://github.com/GetFirefly/firefly#runtime https://github.com/GetFirefly/firefly#runtime Generally it should be assumed that actors and their concurrency model is fully supported as that is a part of the core semantics for BEAM languages.
    - illiarian 4y ago
      > as that is a part of the core semantics for BEAM languages. It's a part of the semantics of the runtime: - an actor is all but guaranteed to not bring down the runtime - an actor is all but guaranteed to never affect other actors - runtime knows how put processes to sleep until the message they listen to arrives. This means all functions are re-entrant. Well, any process is put to sleep after a cretain number of reductions so that no process takes away time from other processes. - runtime all but guarantees that process errors are a) isolated and b) propagated. That is when a process dies all other processes that monitor it are guaranteed to receive a notification. That's why supervision hierarchies in Erlang are possible
      - 4y ago

I may be wrong but, “designed for WebAssembly” might be the key selling point here. I imagine we would be able to write elixir on the frontend with this.

throwawaymaths 4y ago
If I were to try to do a straight shot at getting elixir on the frontend I'd just send bytecode up to the frontend and interpret it, either in js or wasm. Erlang bytecode is fairly straightforward, and especially if you stay single threaded you can make a reasonable approximation of the compute model[0]. The hardest parts I imagine would be coming up with an abstraction that lets you manipulate the DOM and test it while staying in the elixir test environment, which is insanely good. I don't see how firefly makes that particular challenge any easier. I feel like the dockyard folks just got rust crazy and decided to do this -- for reasons[1], rust is honestly not the best language to do a BEAM implementation in, which is I think why they pivoted to a compiler [0] except for the fact that a lot of libraries unnecessarily spawn processes. [1] https://www.erlang.org/doc/man/erts_alloc.html https://www.erlang.org/doc/man/erts_alloc.html
- illiarian 4y ago
  > If I were to try to do a straight shot at getting elixir on the frontend I'd ... use LiveView :)
  - throwawaymaths 4y ago
    Like this proposes eventually obviating the need for things like LiveView.JS, LiveView hooks, etc.
- yellowapple 4y ago
  > except for the fact that a lot of libraries unnecessarily spawn processes. Well yeah, that's kinda the whole point of Erlang in the first place :)
bhaney 4y ago
Pretty much exactly that, yeah. From the README: > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development
lolinder 4y ago
Phoenix+LiveView already seems to do this really well—what's the niche for an Elixir SPA?
- rkangel 4y ago
  I'm a big fan of LiveView, but when you get to a very high degree of interactivity or anything that needs to work well offline or with bad signal quality then LiveView is not the right choice.
  - POiNTx 4y ago
    For very high degree of interactivity I've been working on LiveSvelte which might solve that issue for you. Your other points still stand though. https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
- victorbjorklund 4y ago
  You can build an app that runs entirely in the browser eliminating the need to have a server and reducing latency. Of course it doesn't make sense for all use cases but for some apps it might make a lot of sense. For example that is how Liveview Desktop works.

manveru 4y ago

See the about section: https://github.com/GetFirefly/firefly#about-firefly https://github.com/GetFirefly/firefly#about-firefly > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development. It is also possible to use Firefly to target other platforms as well, by producing self-contained executables on platforms such as x86.

rektide 4y ago
Great! Nice. Very neat possibilities here. I'd be very very interested to hear follow up, on how Firefly does actors. I feel like there's so many potential ways to target wasm, but the high concurrency spirit of Beam has such unique flavor. I'd love to read in & hear that spirit is well preserved.
- madsbuch 4y ago
  There are details on this also: https://github.com/GetFirefly/firefly#runtime https://github.com/GetFirefly/firefly#runtime Generally it should be assumed that actors and their concurrency model is fully supported as that is a part of the core semantics for BEAM languages.
  - illiarian 4y ago
    > as that is a part of the core semantics for BEAM languages. It's a part of the semantics of the runtime: - an actor is all but guaranteed to not bring down the runtime - an actor is all but guaranteed to never affect other actors - runtime knows how put processes to sleep until the message they listen to arrives. This means all functions are re-entrant. Well, any process is put to sleep after a cretain number of reductions so that no process takes away time from other processes. - runtime all but guarantees that process errors are a) isolated and b) propagated. That is when a process dies all other processes that monitor it are guaranteed to receive a notification. That's why supervision hierarchies in Erlang are possible
    - 4y ago