“Submillisecond LiveView” is written in Rust. I wonder where its approach and behavior differ from that of Elixir-based LiveView (eg, in state maintenance). Anyone have a clue to offer?
-r
1 Like
Well … without checking this project I would say we have a better community. 
Ok, now more seriously … Regardless of LiveView implementation there’s still a key differences between languages that simply can’t be skipped … Also the initial commit was pushed 2 months ago, it does not links to any documentation, does not have any releases as well as tags and it still have lots of features missing like components (see created issue).
I think it’s way too early to start a real analyze/comparison of this project.
4 Likes
Yes it’s super early days for this project but nice to see other languages and frameworks be inspired by the Phoenix Liveview ideas! AFAICS this project aims to write rust that runs both in the browser (using WASM) and server but is not just ordinary Rust but using a specific runtime behind it.
I’m following that runtime project behind it for a while now. This framework is not ‘just’ written in Rust but in some “dialect” if you would call it that. The idea is to write it in rust and use WASM as target and then run it inside a specially crafted runtime that behaves in a way like the BEAM VM (also being inspired by it). Every instruction that a process is running on it will have a cost, and it will pre-emptively run all processes evenly just like the BEAM VM and also with massive concurrency as goal. (for a better explanation see: https://lunatic.solutions/ )
The dialect part is explained in a blog post here: Rust without the async (hard) part | Lunatic
It’s “removing” the async/await keywords and handling this inside of the (WASM) runtime.
4 Likes
I’m one of the authors of submillisecond.
Like @rjk already mentioned, I think the biggest difference is not Rust, but the fact that we target the lunatic vm. The Rust code gets compiled to WebAssembly modules. The modules are then turned into WebAssembly instances and those instances are similar to Erlang processes, we even call them processes. They are lightweight, fast to spawn and completely separate (get their own heap and stack). So you are able to build systems in Rust (or any language that compiles to Wasm) that have similar characteristics to Erlang systems.
The WebAssembly aspect of it also opens a bunch of other possibilities. Things that would be impossible to do in Elixir. For example, WebAssembly can run in the browser. So we are working on moving some parts of the view into the browser. You still write all of the logic in Rust, but rarely need to actually send data to the backend because the code just runs in the browser. We are also thinking of just moving the whole backend into the browser for offline-first apps (SQLite can already run in the browser).
It’s still super early days and we need to solve many difficult technical problems (syncing state between offline apps and backend, splitting code into different .wasm compilation units, …), but we see a lot of potential here and will keep iterating on it. 
14 Likes
