3 ms·

It seems I've been in my "ignore all new tech stuff" hole for too long when I open a project link and don't understand most of the value/code. It seems very int

It seems I've been in my "ignore all new tech stuff" hole for too long when I open a project link and don't understand most of the value/code. It seems very interesting though, I am not knocking the project at all. So, I write code that compiles to WASM, and then pass that code as a process to Lunatic? Is this pattern intended to be a generation beyond microservices/containers, where rather than writing a "service" that gets put into a container and then managed by a container orchestrator, you're creating processes that get managed by a process manager? To get rid of the container overhead? If that's true, isn't it just all turtles because Lunatic will have to run out of containers (and presumably those will have to be managed/orchestrated)?

ReactiveJelly 6y ago
I don't think the point is to reduce overhead. It may actually increase it, as long as the overhead for AOT wasm is more than 0. [1] As I understand it, containers have almost no CPU overhead. I have no citation for that. Lunatic, to me, looks more like a web browser hosting many JavaScript sandboxes. But instead of JavaScript it's wasm, and instead of a web browser, it's only a host process, like node.js. (I don't know if node.js has a concept of running many side-by-side JS actors. Maybe it does) So you have 1 Unix process hosting many Erlang-like actor processes. I'm writing a little bit out of my depth, but I think the huge difference is permissions. Sure, this all might be possible with containers. But Docker, the only container system I've used, is this huge thing. You have to install it, there's a daemon, it hooks into systemd probably, usually you need to be root unless you do everything just right. It requires kernel support for lxc, so I can't run it on the crappy little ARM boards I have to program. Lunatic, like a web browser hosting JS sandboxes, is _just_ a Unix process. No root, no permissions. I think it will even work on Windows and OS X. So yeah, if you're talking about web services where you can already manage many Docker containers on a Linux host no-sweat, it might not add much. But if this can be deployed on arbitrary clients with no root and no Linux kernel dependency, it's a very fun toy that must be useful for _something_. [1] You may find this cool: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox has a C++ font shaping library. Starting in FF 75, they compile the C++ to webasm, then AOT compile the webasm into native code. Resulting in a memory-safe sandbox for C++. There is some overhead, and it looks like a lot of set-up work. They don't give exact percent numbers on runtime overhead. I don't know if Lunatic is doing JIT or AOT. I'll generously assume that one day they'll do whatever is faster. Part of the point of wasm is to beat JS performance, so I think at least compared to Electron or Node.js (JS sandboxes in a Unix process) it should be competitive.
elcritch 6y ago
It's more about fine grained control of errors. WASM/Lunatic could bring many of the benefits of Erlang application design to any wasm friendly language. The creator of Elixir has a nice writeup of the Actor mentality and k8s: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/ http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...

ReactiveJelly 6y ago

I don't think the point is to reduce overhead. It may actually increase it, as long as the overhead for AOT wasm is more than 0. [1] As I understand it, containers have almost no CPU overhead. I have no citation for that. Lunatic, to me, looks more like a web browser hosting many JavaScript sandboxes. But instead of JavaScript it's wasm, and instead of a web browser, it's only a host process, like node.js. (I don't know if node.js has a concept of running many side-by-side JS actors. Maybe it does) So you have 1 Unix process hosting many Erlang-like actor processes. I'm writing a little bit out of my depth, but I think the huge difference is permissions. Sure, this all might be possible with containers. But Docker, the only container system I've used, is this huge thing. You have to install it, there's a daemon, it hooks into systemd probably, usually you need to be root unless you do everything just right. It requires kernel support for lxc, so I can't run it on the crappy little ARM boards I have to program. Lunatic, like a web browser hosting JS sandboxes, is _just_ a Unix process. No root, no permissions. I think it will even work on Windows and OS X. So yeah, if you're talking about web services where you can already manage many Docker containers on a Linux host no-sweat, it might not add much. But if this can be deployed on arbitrary clients with no root and no Linux kernel dependency, it's a very fun toy that must be useful for _something_. [1] You may find this cool: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox has a C++ font shaping library. Starting in FF 75, they compile the C++ to webasm, then AOT compile the webasm into native code. Resulting in a memory-safe sandbox for C++. There is some overhead, and it looks like a lot of set-up work. They don't give exact percent numbers on runtime overhead. I don't know if Lunatic is doing JIT or AOT. I'll generously assume that one day they'll do whatever is faster. Part of the point of wasm is to beat JS performance, so I think at least compared to Electron or Node.js (JS sandboxes in a Unix process) it should be competitive.

elcritch 6y ago

It's more about fine grained control of errors. WASM/Lunatic could bring many of the benefits of Erlang application design to any wasm friendly language. The creator of Elixir has a nice writeup of the Actor mentality and k8s: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/ http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...