[maxmcd]

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. (edit: this also might be out of date, maybe wasi solves a lot of this)

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 this. 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".

[withtypes]

We will take a look at embly! For Rust currently you just have to add wasm32-wasi target and compile for it. There are still some problems (WASI is not yet finished, maybe binary size could be optimized). Our current idea is to build a small cargo command which would do building and deploying. Wasmer is doing great work with tooling for other languages. We are now focused on Rust and AssemblyScript, but as Wasm and WASI mature we would like to simplify it for more languages.

We have been thinking about live process migration. I’m planning to do a demo where we run a lot of board games (e.g. chess) on authoritative servers using Lunatic. Then we give a developer ability to move a live game to a different machine without players noticing. We are still working out the details, but that area also excites us!

[infogulch]

Factorio is a 2d game where logistics is one of the core problems players have to solve. When they implemented multiplayer they went for the "every player/server simulates the whole game perfectly deterministically"-strategy which is great imo, but it begs the question: what happens when simulations diverge? They call it Desyncronization [1], and it's considered a bug.

They had lots of desyncs at first, but nowadays Factorio is fantastically stable in this respect. One of the tools they developed for themselves to achieve this (and the reason why I'm bringing up Factorio here) is called "Heavy Mode" [2], which is a game option that saves & reloads the full game state on every tick (the game targets 60 ticks/s), and compares the before/after states for inconsistencies.

Perhaps a similar "Heavy Mode" for Wasm live migrations could aid in hardening such a feature. E.g. spawn two instances of the same process on different hosts, and migrate both to new hosts every, say, 100k instructions, comparing a hash of their serialized representations at each migration.

[1]: https://wiki.factorio.com/Desynchronization

[2]: https://www.factorio.com/blog/post/fff-63

[bkolobara]

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.

[elcritch]

It'd be great to see C/C++ be easy to integrate. I can't quite tell if there's support for them? There's so many existing C/C++ code bases that are security nightmares but still provide great functionality. Wrapping it in a secure context would be awesome.

Also it'd be fantastic to be able to compile Nim as well. Maybe a weekend project. :-)

[bkolobara]

C/C++ has great WebAssembly support and we definitely want to provide a Lunatic library for it. We would love to see the community getting involved and contributing other languages that we have less experience with, including Nim.

[elcritch]

If you provide a C library then it'll be super easy to add Nim support!