Pedantic but just for drive-by readers, there isn't really any nodejs dependency. You can use it to manage JS dependencies, or you can forgo it for "vendoring" with esbuild (or bun, etc).
Liveview itself has a small JS component that is mostly transparent (socket.connect() basically). You can of course add more JS too it.
Wow. This paper is _very_ well written. I am not an expert in neural networks, but the concepts were very well described and diagramed and I was able to follow along.
I would read a whole book about neural networks written in this style.
Normally, ML training is via back propagation, which is a synchronous technique. If you try to trivially parallelize, it doesn't work, for reasons (tm).
This lets you train a machine learning model of arbitrary size (bigger than can fit on a GPU, or even a multigpu node) using an actor-based distributed technique. There is a slight training cycles count penalty but it's way less than the cost of coordination.
I love Elixir and Phoenix/LiveView, but I have the same problem. I think it will need to gain the proverbial 10x improvement over React and JS frameworks in general before people consider it.
Sometimes you can come in the side door. I built a testbed reservation app for the GUI team I work with using Phoenix LiveView. The Product manager was surprised out fast I hammered it out. So far everyone is using it without a hitch. It's not product code, but it's still in active use with no problems.
not just this, but also no one knows elixir. Its a very niche language for very niche set of tasks, rewriting existing apps form react to elixir just to use liveview is a pointless overkill
Front-end developers love the LiveView model with functional components, no state, and light node.js dependency.
Backend developers get a process/actor + OTP supervision tree that's second to none. Horizontally scalable, functional, and pretty simple at its core.
Fullstack developers get to transition seamlessly.
I've really enjoyed using it while building.