bcardarella

Video: https://x.com/chris_mccord/status/1923417060593356889

The amazing thing about Erlang and the BEAM is it's depth of features. To the OP the Behaviour/Interface of Erlang is their biggest take away. For me I believe it is how you require far far less development resources to build complex systems than you would require in any other language (provided comparable experience in both stacks). And for many the lightweight processes and programming model.

OTP itself has so much in it. We've been working on compiling Elixir to run on iOS devices. Not only can we do that through the release process but through using the ei library provided in Erlang we can compile a Node in C that will interface with any other Erlang node over a typical distributed network as you would for Erlang, Elixir, Gleam, etc... furthermore there is a rpc library in Erlang where from C we can make function calls and interface with our Elixir application. Yes, the encoding/decoding has an overhead and FFI would be faster but we're still way within our latency budget and we got this stood up in a few days without even have heard of it before.

The larger point here is that Erlang has been solving many of the problems that modern tech stacks are struggling with and it has solved for scale and implementation cost and it solved these problems decades ago. I know HN has a bit of a click-bait love relationship with Erlang/Elixir but it hasn't translated over to adoption and there are companies that are just burning money trying to do what you get out of the box for free with the Erlang stack.

This is the common misconception of LiveView coming from the JS community. LiveView is JS. It has a whole optimistic UI layer that solves all of the problems you cite. The UI from state updates coming from the server or the client doesn't matter because the reactive UIs of SPAs still require data updates from some remote source. So if we're talking about latency that latency is going to exist for all application types.

Well, we've had a bit of a set back on the Jetpack client. Unfortunately the Jetpack developer just moved on to another position. The client is nearly ready but kind of a kick in the pants to have to find someone new right now.

I wrote my thoughts on the LiveView 1.0 release: https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1...

Why are you guys hijacking the scroll bar on your website?

I was not referring to React Native, I was referring to Turbo Native. We've often been mistaken as a WebView and not actually "native".

Our position is the build once, run anywhere isn't ideal for many use cases. When we target the actual UI frameworks we are automatically opted into a huge ecosystem that is already built for us. We allow Apple and Google to do all of the work of building and documenting the UI framework and developing apps that feel best on each platform. The other advantage is we can target every single device. For example, LiveView Native already supports iPhone, iPad, MacOS, AppleTV, AppleWatch, Apple Vision Pro. We can build for anything that SwiftUI can target. The same will be the case with Android/Jetpack.

As far as the implementation cost, our position is that managing the state on each device is a big time sink. We remove this repetition. Also, we can abstract above the markup with LiveView function components. The components compile out to the platform-specific markup. As we develop that I feel most people will be working mostly in the higher abstraction.

We have the same strategy as LiveView. We attempt to reconnect when network is lost. There are methods for restoring your state as well that work in LiveView and LiveView Native

LVN actually wraps the 1st class native UI framework. So we are not rendering out our own UI or using a WebView to render HTML/CSS with a JS bridge.

Similar to LiveView itself, we manage state and event handlers server-side.

I'm the lead on the LiveView Native (LVN) project. Happy to answer any questions here. I'll get a few FAQs out of the way:

* it's not a WebView - we render actual native UI

* we do not push for 100% server-side rendering. An upcoming post will discuss optimistic UI strategies for LVN

* Android support is coming, possibly before EOY

* offline mode is not yet implemented but coming

He's literally building a type system for Elixir. What the hell are you talking about?

Vendoring the binary guarantees that I control what is running. It isn't installed, just run locally from the lib. I'll quote the OP issue on GH:

> Now I found that it downloads (here) even some proprietary binary from https://supermaven.com, i.e. unaudited and unauditable code, without any verification (except TLS)!

This opens Zed up to Man In The Middle attacks and Supply Chain attacks. And now that Zed has indicated that they won't fix the door is wide open to these vulnerabilities.

Actually, I'll do one better. For a rather large framework we are developing an engineer at DY introduced a somewhat similar problem. A binary was being installed, from a trusted source in this case but a binary was being compiled/installed none the less. It never made its way to an actual release and I personally took the time to change this approach so that we weren't installing binaries on people's machines without their permission. We now pre-compile and vendor. This approach likely isn't what Zed can do as in this case we can target just Intel/Apple Silicon machines but the point here is I recognized the problem and rather than just hand-wave dismiss it as a #wontfix I took responsibility for it and fixed it myself. It cost money, it cost time. I still fixed it because that's the right thing to do.

https://github.com/liveview-native/liveview-client-swiftui/p...

Compassion for those putting others in harms way is such a stupid take.

I'll add that security incidents through mistakes happen. Conscious decisions to punt on user security in the name of faster release cycles isn't something I am willing to have compassion on.

We don't cut corners like this so no, that wouldn't happen

I just don't buy this argument. None of what you've listed gives the right to install binaries without permission. A simple opt-in notification could resolve this but they decided against this for ease of use. Free or not, pre 1.0 or not, small team or not this puts users at risk for a pretty bad attack vector.

Considering how many other solutions that are all trying to solve distributed systems issues but avoiding just using Erlang or Elixir I think the statement has merit.

Ok but where is the ceiling? I was told there would be a ceiling!

I read that title wrong

website comes last

I'll take the opportunity for a shameless plug on LiveView Native. In addition to mobile apps we can also build for desktop, watch, TV, and even Apple Vision Pro. All using LiveView concepts, performance, and ease of development.

What people may not be seeing in this demo is that this is generating in a Phoenix LiveView application.

> Half the libraries we used were abandoned

People really need to unwarp their brains from how they judge libraries in Elixir compared to other ecosystems. Erlang is 30 years old. Elixir sits on top of that stability. Elixir will very likely never reach 2.0 because it doesn't need to. And if a 2.0 does come it will be simply to remove deprecated functionality.

Not having 12 major version releases per year means what you think are "abandoned" are actually stable and perfectly fine to use.

In Elixir, we don't really care about the last time a version was pushed. I regularly use and rely on libraries that haven't been touched in years because they don't need to be touched.

LiveView has streaming. I would argue that if you're stuck in the React way of thinking about application design then it's not worth trying to sell you on what LiveView is doing. But there are multiple case studies out there showing that it results in far less build times than React for no compromise on user experience.

I never used ASP.net so I cannot offer a comparison about what is "better" but your assumption is correct that diffs are through a WS and merged client-side. What this has resulted in is actual order of magnitude of implementation time reduction over the crazier SPA complexity available today. Less time to build, less cost to the company, less bugs in the long run, and a single place to manage and reason about state. It's a win.

We use Svelte along with LiveView in BeaconCMS. There are certainly good use cases for wanting something that has more granular control of the UI on the client but I would caution teams from just going all-in on Svelte + LV for all things. Even with Phoenix using LiveView isn't always the answer as sometimes dead render pages are perfectly fine. Don't all-or-nothing everything.

As the article points out there are some good use cases for deviating from the 'LiveView Way'. I would argue that if you have 1,000ms round trips then there is something else to consider but geographically located servers could be unavailable to your team for a number of reasons (i.e. cost) so adding some client-side state management could be your solution.

We've given up on PWAs. I ran DY as a web-only shop but when I left at the end of 2019 the very first product I wanted to develop was a native app. There's just too many screens now that PWAs can't even hope to deploy to. (watch, tv, AR/VR) So when I came back I wanted to find a way that we could add native as a service offering but not dilute our expertise in Elixir. This is mostly where LiveView Native came from.

In addition to all of our (I'm the DockYard CEO) DockYard Academy training material being written as a Livebook we are also working on the upcoming LiveView Native guides being written as a Livebook along with a self-contained Phoenix instance so you can develop your first LiveView Native apps interactively and see them render as you go in both the Xcode simulator and (eventually) the Android simulator. If/when we get to WinUI3 we'll try to do the same.

Livebook is incredibly powerful and versatile. When the general population finally wakes up to how insanely powerful Elixir is for such little effort, cost, and time to build (compared to other options) they will find an incredibly mature ecosystem of tools and resources ready for consumption.

Climate models are based upon historical data. Recent climate change has changed weather patterns where historical data being used is making predictions less reliable.

All forecasts. I race sailboat around Boston and they've been absolutely horrible. Not just for extreme weather events but even regular weather wind direction is off by nearly 180 degrees in direction regularly, wind strength is regularly wrong too. The predictions overemphasize rain events in the 10 day forecast during the Summer that nearly always completely go away and they fail to predict rain and lightning events. That's overing multiple weather models at various resolutions.