4 ms·
I think it is more exciting and more innovative to think about LiveView as a new architectural approach to building reactive applications. Yes in Elixir land it
by floodfx 3y ago
I think it is more exciting and more innovative to think about LiveView as a new architectural approach to building reactive applications. Yes in Elixir land it is a Process and there are some amazing things about the BEAM. But LiveViews have the potential have an impact beyond just the Elixir ecosystem and folks should embrace that.
I’ve been a part of porting the Phoenix LiveView Protocol to both Javascript (https://LiveViewJS.com https://LiveViewJS.com) and Go (https://github.com/canopyclimate/golive https://github.com/canopyclimate/golive) backends and supported a friend that is porting it to Python.
Ironically I think taking LiveViews outside of Elixir could actually make it easier for folks to adopt Elixir-based LiveViews in the future.
- jolux 3y agoPorting this is cool but why would people adopt Elixir if they can have LiveViews in their preferred language?
- weatherlight 3y agoErgonomics matter. Because outside of Go (and maybe Rust) it will be very difficult to actually do what Elixir does, with the same level of concurrency and fault tolerance, etc, with the same ergonomics. Ruby/Rails/StimulusReflex does something very similar, but kind of falls over unless you replace ActionCable with AnyCable which is written in Go. So now, you have to support Go and Ruby runtimes. Some developer who decided that the above was a nightmare to work with, __might__ start a new project in Elixir, to get something that actually does what Elixir does instead of just mimicking it. I'm not sure I buy this, personally, but I can understand the argument.
- troupo 3y ago> Because outside of Go (and maybe Rust) it will be very difficult to actually do what Elixir does It's just as difficult in Go and Rust. BEAM, the Erlang VM that powers Elixir, is not just about lightweight processes. It's also about guarantees that neither Go nor Rust provide. E.g. to do what Elixir does you need robust process supervision trees. You can imitate, but not replicate those in other languages.
- thomasfortes 3y agoVirding's Law: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
- floodfx 3y agoComments like this push people away from Erlang rather than draw them in.
- troupo 3y agoI find it quite the opposite: what is it that other languages are trying to re-implement, and why they can't?
- thomasfortes 3y agoIt's a play on https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- Rapzid 3y agoAnd yet it doesn't matter.
- troupo 3y agoIt should. Then in the vast majority of cases we wouldn't run kubernetes clusters running docker containers for one-off tasks and single services. Or "serverless functions". Unfortunately even the otherwise very smart folks of Go and Rust only see "ah, lightweight threads, got you". That's why, for example, you get irrecoverable panics in both languages and awkward attempts to patch over them in later versions. Meanwhile Armstrong's thesis "Making reliable distributed software in the presence of hardware/software errors" is over thirty years old now.
- Rapzid 3y ago
- floodfx 3y agoUnderstanding LiveViews as a concept could make it easier to commit to learning a new language. I am not saying one should but that one could and it would probably be easier since you don't have the additional overhead of also learning what is a LiveView.
- epolanski 3y agoSame reason why people may get hooked on some fp library can lead to them trying Haskell.
- ziftface 3y agoIs your friend's python library open source by any chance? I was thinking about doing the same.
- floodfx 3y agohttps://github.com/ogrodnek/pyview https://github.com/ogrodnek/pyview