embly VS chat

Hey, I tried to build something like this too: https://github.com/embly/embly

My takeaway after building that is that the build tooling is the major pain point. If you're trying to onboard someone onto this platform from their favorite language the hard part is getting from code to the .wasm file. wasm-bindgen (as an example) has put so much effort into build tooling, I wonder if that's a necessary path for success here.

It's also great that WASI exists now, if I had to do embly again I'd just use wasi and then implement all of my "platform" features as filesystem features, not syscalls. If your API interface is the filesystem then you could provide interoperability between environments. Let's say you want to include a key-value store in the wasi runtime, you just make the keys files and the values file contents. Then you could so something like ship a FUSE filesystem to interact with the filesystem in the same way from a traditional VM or on a personal computer. I got really bogged down in custom syscalls and this path seems potentially more elegant.

Have you also thought about live process migration? I got really excited about this from a technical standpoint. Since you completely control the runtime you could set up a clustered wasm solution that moves long running processes from VM to VM by sending their live memory state to another machine. Not sure if that's actually useful, but cool that it's not bogged down by the usual complexities of doing the same in a full OS environment.

Anyway, so glad to see that someone is taking this idea on. Please make a cloud platform and let me pay for it. Also happy to chat more if any of this is useful, I've joined your discord as "max".

TUIs over ssh/telnet can be a lot of fun. Especially in cases where multiple people can interact with each other on the server. It simplifies the programming model as you only have one state on the backend that you render to multiple connections. Syncing up everyone becomes trivial. You can also use some React concepts, like rendering a virtual TUI and sending just the right set of minimal escape sequences back to the user to bring their display up to date.

A few months ago I implemented a telnet chat server[0] for fun and it was surprisingly easy to do so. Even by using a wasm vm that I was still working on at the same time.

[0]: https://github.com/lunatic-solutions/chat

We are investing a lot of effort into making Lunatic feel native to the particular language and ecosystem. If you look at the Rust chat server we built in Lunatic (https://github.com/lunatic-solutions/chat), it fully integrates with cargo. You just run your typical “cargo run” command, it will compile the app to wasm and use lunatic to run it. If you want to run your test, you can just do “cargo test”.

wasm-bindgen is necessary only because it’s really hard right now to merge the wasm world and the JS one in the browser. We have the advantage here of staying out of the browser.

It took me around a week to build it with Rust + Lunatic and you can check out the code here. If you would like to try it out you can connect to it with:

Recently I implemented a command line chat server in Rust using an actor framework. I model each TCP connection as an actor.

Hi HN,

I'm working on an Erlang inspired WebAssembly runtime for the backend[0]. Recently I added TCP support and was looking for apps I could build with it. I ended up building a telnet line chat app. It was a great dogfooding experience and has a nice retro feel to it.

You can access the US server with:

> telnet lunatic.chat

or the EU one with:

> telnet eu.lunatic.chat

Pick the one closer to you, as all the rendering is done on the backend and lower latency will mean better UX.

The server is open source[1] and written in Rust. The Rust code is then compiled to WebAssembly and runs on top of Lunatic. Each connection runs in a separate (lightweight) process, has it's own state and sends just a diff of esc-sequences back to the terminal to bring it up to date with the current render buffer. Everything is deployed to an ARM Linux box.

[0]: https://github.com/lunatic-solutions/lunatic

[1]: https://github.com/lunatic-solutions/chat

The server is open source and written in Rust. The Rust code is then compiled to WebAssembly and runs on top of Lunatic. Each connection runs in a separate (lightweight) process, has it's own state and sends just a diff of esc-sequences back to the terminal to bring it up to date with the current render buffer. Everything is deployed to an ARM Linux box.