Thanks! WebAssembly gives Modus some superpowers, including polyglot language support, near-native performance, and sandboxed isolation. On each of these points:
- 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.
This also happened on Leap Day 2020 with Onity locks used in Crown Plaza Hotels. See https://i.imgur.com/GI5A3jW.png. I wonder if it's the same issue never fixed? Can you share with us the hotel chain and/or the lock manufacturer? Thanks.
Fascinating. I presume you were born on Feb 29 of 2004 or earlier. What did the system do when you tried to purchase? I'm curious how the error manifested. Thanks.
- 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! :)