the C code is compiled to WASM bytecodes, they are interpreted in a WASM VM. If the C function crash, it does it inside the VM, so the crash is contained.
Why is it misleading? If BEAM could isolate crashes in NIFs, it absolutely would. Either way the point is that you are able to leverage C code (though in Rust's case the point is just to leverage existing code, since you don't need to drop into C for performance).
Because you are not actually calling a native compiled C lib you are calling wasm code. A lot of the time you can not compile the C code to wasm and what do you do then? How do you interface with OS libraries?
You may be focusing too closely on the C aspect; the point of the demonstration in the OP is to show that Lunatic can gracefully sandbox and interoperate with any code that can be compiled to WASM, of which C code is just one example. Ideally you wouldn't need to access any OS libs from within the sandbox (indeed, much of the point of the sandbox is to provide alternatives to OS facilities), and even if you did you could still access those libs in an un-sandboxed form from within your ordinary Rust code (and yes, crashing at that point would take down the process, but it's still strictly better to have an option to run C code that doesn't take down the process when crashing).
Agreed. It's not a "foreign" function if everything is in WASM. All the VM sees is WASM code; it doesn't make a difference if it was originally written in C or Rust.
"Foreignness" is an incidental property, the actual goal is interoperation. Being able to interoperate with C code from within the sandbox is both useful and something that BEAM doesn't do. In the meantime, there's nothing preventing anyone from doing regular FFI from within the part of the Rust program that lives outside of Lunatic, if for whatever reason the sandbox is insufficient.
I don't know much about WASM, but how does this work with shared libraries? Is it even possible to call a shared library without any safety guarantees?
WASM runs in a sandbox, it's not possible to call a shared library directly in the same way as you do in C... all sys calls are "imported" functions that a host exposes to the WASM code running... this host has the ability to do anything around a sys call, which is likely how they manage to forbid access to network/filesystem for example.
The host can be the browser when running on the browser, or it can be one of the WASM runtimes (wasmtime, wasmer, Lucet)
