Rich_Morin
“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
Trending in Discussions
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
New
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Quite interesting article Google brought me. Didn’t find any mentions about it here.
What do you think in general? Would you use togethe...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
A little off-topic, but I feel like people here have a good head on their shoulders.
I used to be quite good at making software. Was luc...
New
Hi there! :wave:
@frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
Other Trending Topics
Edit: 2026 May 15 - This post is archived.
Mob is alive!!
Main docs: mob v0.7.11 — Documentation
A bit of explanation for the slightly c...
New
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Latest Phoenix Threads
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex











Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Eiji
Well … without checking this project I would say we have a better community.
Ok, now more seriously … Regardless of
LiveViewimplementation 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.
rjk
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.
bkolobara
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
lunaticvm. 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.