Find a file
2023-11-10 19:39:53 -06:00
.cargo WIP 2023-11-10 14:57:20 -06:00
src Good try 2023-11-10 17:10:36 -06:00
static Good try 2023-11-10 17:10:36 -06:00
.envrc WIP 2023-11-10 14:57:20 -06:00
.gitignore WIP 2023-11-10 14:57:20 -06:00
Cargo.lock WIP 2023-11-10 14:57:20 -06:00
Cargo.toml WIP 2023-11-10 14:57:20 -06:00
flake.lock WIP 2023-11-10 14:57:20 -06:00
flake.nix WIP 2023-11-10 14:57:20 -06:00
readme.md Add final notes 2023-11-10 19:39:53 -06:00
rust-toolchain.toml WIP 2023-11-10 14:57:20 -06:00

Why

I think something like this is the fuuuuuture. A Rust-core, almost-erlang runtime for wasm has so many insane possibilities and possible promises that it's impossible to ignore.

However, this tiny counter example currently uses ~150MB of memory on my machine. With space optimizations, I still end up at ~122MB.

I think I value being small too much. Or perhaps the runtime does indeed provide a huge featureset.

  • What does wasmtime/wasi include? (wastime is roughtly a 30MB binary -- 28MB stripped)
  • What does lunatic include? (29MB, 22MB stripped)
  • What all does submillisecond and sms_live include? (probably not much since the wasm bytecode is 1.2MB, but even that is pretty large IMO)

I also found that sending messages to a LiveView process was troublesome -- as in, I couldn't figure it out.

https://discord.com/channels/779332282531184680/1013844381683417138/1172673863839137883

At this point, I think I shall turn to "normal" async Rust