HN Explorer

Launch HN: Lunatic (YC W21) – An Erlang Inspired WebAssembly Platform

162 points by withtypes ↗ HN
Hi HN! We’re Bernard & Hrvoje and we are Lunatic (https://lunatic.solutions/). Our goal is to improve how you run server-side code by building an open-source runtime that gives you lightweight processes, fault tolerance, and capability-based security for different parts of the application. Basically, we want to combine the power of Erlang with WebAssembly and bring that to new and existing applications.

The two of us met in high school, studied computer science together, but then went separate ways working as backend engineers. Bernard worked at CERN and Hrvoje co-founded Amodo, an insurance tech startup. Bernard, being a huge fan of Erlang/Elixir, started working on a similar open-source runtime for WebAssembly which he called Lunatic (https://github.com/lunatic-solutions/lunatic).

Lunatic runs Wasm modules as lightweight processes with its own heap/stack and preemptively schedules them on a multi-threaded executor. You can spawn those processes using a library we provide (currently for Rust and AssemblyScript) to enable actor-based architectures with message passing. Scheduling is implemented by modifying a Wasm module and adding “reduction counts” (similar to Erlang). You can write seemingly blocking code but it won’t actually block the underlying OS thread as our implementation of WebAssembly System Interface (WASI, think of it as POSIX syscalls) will be implemented with async Rust and a bit of magic [0] :) The code is JIT’ed and we build on top of existing Wasm runtimes Wasmtime/Wasmer for this part (codegen is done by LLVM or Cranelift).

To step back from technical details, working on Lunatic for the past few months, we have started to form a bigger picture about server-side applications. Over the years we have witnessed many trends: Docker & containers became popular, asynchronous programming and green threads are ubiquitous for IO intense work, polyglot codebases are always present, microservice architecture became popular, and distributed is being used both for scale and to bring computation closer to clients to lower latency. Two important driving forces are hardware capabilities and how we develop software. Those have changed dramatically from the time operating systems were created.

For example, to maximize resource usage of a single machine, we started running virtual machines and then moved to more lightweight containers, both to give isolation and sandboxing to different applications. Serverless is pushing this even further. Lunatic builds on top of WebAssembly security principles [1] to give sandboxing and isolation to enable even more lightweight environments.

Servers also needed to handle more and more network connections and spawning an OS thread per connection became problematic so developers used different programming patterns, async implementations, or user-space threads/processes to tackle this problem. Lunatic solves this by using Erlang’s proven approach [2].

How we develop software has also changed. Today most of our application consists of third-party libraries and it’s common to have hundreds or even thousands of dependencies and obviously it’s impossible to audit them all. When you compile and run your application, the whole code has the same privileges, so a malicious dependency could easily steal your private keys.[3,4,5] WebAssembly is trying to standardise ideas like Interface Types and dynamic linking between Wasm modules. We could isolate libraries into different modules based on capabilities they require (which “system calls” they use) and let developers decide which parts of their app have what capabilities.

Other use-cases that Lunatic and Wasm enable are plugin architecture to run third-party code, sharing code between frontend and backend, polyglot codebases that use Wasm interface types to call each other functions, etc....

39 comments

[ 6.1 ms ] story [ 98.9 ms ] thread
weego
There's an awful lot of verbiage but none of it really tells me in why or what situations or domains I'd find this compelling. I'm impressed conceptually but like are we talking 'bring your favourite language to a highly fault tolerant nodejs replacement'? Or I'm off the mark? The site is similarly vague.
withtypes
You are thinking in the right direction, but there are some technical differences between how NodeJS works compared to Erlang or Go. For example, in NodeJS you could accidentally block the event loop by some unintended computation, but Lunatic and Erlang periodically give control back to the runtime. We also want to abstract the syscall layer, for example, in our lunatic.run demo, you write a program which seemingly uses standard input/output but we actually read/write from a socket.

By the way, if it sounds vague, that's important info for us, we have to improve that!

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

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!
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

dataangel
My excitement around Lunatic is mostly from being able to write a native application in Rust that I know won't have memory issues (b/c Rust borrow checker) and where I know bad plugins can be reliably killed (b/c lunatic reduction counts) without killing the whole application. Trying to be an OS replacement sounds cool, but I hope lunatic doesn't lose sight of this already worthy use case :) As soon as lunatic has a way for me to link native libraries (e.g. making lunatic usable as a library for a regular Rust app, so the core can call native libs) and supervise processes (so I can kill the bad plugins) I'm all aboard.
withtypes
We agree with you, we are currently focused only on runtime running on an existing OS. We know there are different uses-cases so we could organize the project so that you can use what you need. In theory, you could use it right now inside of your Rust app to run plugins as Lunatic processes, but we need to document it a little bit better and maybe showcase an example.
bglusman
Curious how this differs from Lumen? I guess it’s not aiming for actual ability to target Lunatic with BEAM languages, but that seems like a disadvantage rather than an advantage, so curious what the advantages are? I guess focus on integration/OS like services perhaps?

https://getlumen.org/ https://github.com/lumen/lumen

bkolobara
We have different goals from Lumen. Lumen is bringing BEAM languages to WebAssembly by running the whole Erlang runtime inside a WebAssembly instance. Lunatic is bringing the concepts of Erlang (fault tolerance & concurrency) to other languages. We are using WebAssembly instances as a replacement for Erlang’s processes. This gives us even stronger per process isolation.
nojvek
I 100% agree with some of the trends you mentioned

1) lightweight isolated computation - VMs, containers and the lot.

2) asynchronous io - user space green threads, epoll, event loops and the likes to have single OS process handle 1000s of connections

3) distributed - scale up compute + have it run close to user. Cloudflare workers, edge@lambda, fly.io. They’re all moving to this direction.

4) polyglot micro services - rather than one big thing written in a single language, many small things that talk to each other via HTTP & grpc. They can be independently changed and scaled up without having to restart the whole system.

Erlang + webassembly are a great fit for this paradigm.

Seeing the success of fly.io, Cloudflare workers and other cloud providers, this definitely has legs and I would love to try it out.

amelius
> lightweight isolated computation

Sounds good, as long as we can have structural sharing between processes on the same CPU, for performance.

withtypes
Fly.io is doing cool stuff! We will try out their platform to deploy Lunatic to the edge.
otabdeveloper4
No offence, but points 1-4 are the year 2000's solutions to 1990's problems.

Programming is an infuriatingly obtuse and, well, stupid discipline.

iamwil
It seems like lunatic is an open source lib with two different licenses. Is it that you can pick either one? Or is it the...union of the two licenses?

It's probably early, but how are you planning on making money? If I build on top of this, I don't want the rug to be pulled out from under me.

bkolobara
Yes, you can pick the one you prefer. Regarding making money, we have not worked out the details and we would definitely like to include feedback from the community. The core will stay open source, we might build some plugins/integrations under a different licence and offer a hosting service.
iamwil
how come Lunatic supports both wasmtime and wasmer? Why those two runtimes and why not some other one like wasm3?

I'm not for or against any of them. I'm just wondering what criteria there was in choosing those two rather than any others, since I only have a cursory overview of the different WASM runtimes.

withtypes
Wasmtime/Wasmer are both written in Rust so it was easy to integrate them. By the way, Wasm3 is an interpreter, not a JIT compiler, but this also has some use cases! For example, running an instance from “cold storage” requires a JIT compilation step which might take more time then just interpreting it. It would be cool to have a fast interpret like Wasm3 too.

We’ve created a crate “uptown_funk” which enables us to write Rust code which easily integrates with both Wasmer and Wasmtime. It was very helpful in implementing WASI and it takes a little bit different approach than Wasmer and Wasmtime. Regarding, Wasmer vs. Wasmtime, we don’t have a preference yet, both are great!

eyberg
Has there been any traction or even ideas on fixing the issue that there is no read-only memory in web assembly?

Sounds completely unsafe to use without.

fgmalpha
It would be great if you guys could participate in the stack switching effort in the Wasm CG.
rapsey
You have a very tough road ahead (as a business). Not because you are not making sense, but because widespread tech adoption is fad based and generally a function of two factors. Who is behind them (google with go, netflix with microservices) and low barrier to entry (mongodb, node.js).
bkolobara
We have an advantage here because we are building on top of existing technologies (WebAssembly, Wasmer, …), but combining them in a novel way. Developers in our community are already building web frameworks in Rust, while utilising features of Lunatic today. I believe that being able to provide value this early is going to play an important role in widespread adoption.
skybrian
How does communication between the lightweight processes work? What do the messages look like? Are they copied?
bkolobara
Yes, the data is copied from the memory of one process to another. In the future we want to use the WebAssembly multi-memory proposal to allow processes to share data without copying and reduce overhead in certain cases.
jayy-lmao
Really excited to follow this project. Full stack who loves writing Rust, feeling this could be a really neat symphony of technologies. Was actually just going down a rabbit-hole on BEAM and Lunatic yesterday, so this really scratched my itch.

I saw a bunch of stuff on SSVM and their impressive WASM VM performance [0]. Wondering if this can be of any benefit to Lunatic?

Furthermore, would be really interested in seeing getting started guides / examples / maybe even some tutorial articles on an example or two. This could really help adoption if thats the goal.

[0] https://www.secondstate.io/articles/ssvm-performance/

wcerfgba
What's the origin of the name? 'Lunatic' is an antiquated and ableist term for the mentally ill, so probably not the best name for your product/company.
bkolobara
I was originally working on a programming language that compiled to Lua, so I named it Lunatic. Later I decided to write a runtime for the language and called it Lunatic VM. We ended up with an actor-based language-agnostic runtime, but the original name was kept though it does not have any connections to Lua anymore.
evnix
Is the based on pre-emption or based on an event loop(or co-operative scheduling)? One of the biggest selling points of Erlang is pre-emption
bkolobara
It's preemptive. We use a reduction counter, similar to Erlang's implementation.
kimi
Maybe I'm not getting it but.... why not Elixir/BEAM/OTP? it already does everything.
bionhoward
typo:

"How can Lunatic help with security? WebAssebmly" ...

Looks super cool, I believe it would be cool to make one app which works as a CLI, front-end web client, and back-end server, just by passing different environment vars... can this accomplish that?