- Language support: At the moment we're supporting Go and AssemblyScript. We plan to add more languages in the future. Python is definitely on our wish list. I'm also looking into ways to support advancements in the WASM/WASI space to be more language-neutral in the future (but for now, it's just these languages).
- Performance: We leverage Wazero for its AOT compilation capabilities to take a WASM binary and convert it to a native x86 or arm64 in-memory instruction set. We do this when _loading_ the module, so it's cached and prepared ahead of time - before the function executes. We also do a lot of leg work on building an invocation plan (similar to how a database builds an execution plan) that instructs the Modus runtime in how to marshal data in and out of the WASM memory space on each request, in a manner that is compatible with the guest language's default import and and export calling conventions. Thus when the function runs, the hot path is very fast.
- Sandboxing: Each function call executes in its own dedicated memory space, with its own instance of the compiled wasm module. You could completely crash one instance without ever affecting the another. You can't accidentally leak memory, or access memory of the host process or another function execution, because each function run is starting fresh. On top of that, the only system resources are those explicitly exposed to the function instance. So there's zero risk of (for example) accessing a system credential or spawning some other process.
Hope you'll give it a try! :)