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.
I pulled in moment.js 5 years ago for a suite of state death and birth certificate registration apps we are working on.
Due to the amount of “business logic” and small staff size on these, they take years to roll out. I appreciate that this library will “hold still” for a few years.
Not all of us are churning out a new e-commerce app every 3 months. E.g. we replaced the birth certificate app from the 80s, and I expect some version of our app to be around for at least a decade, albeit with patches for new browsers on the front end and new Java app servers on the back end.
We (the Moment maintainers) have been saying it anecdotally for quite some time. In our respective podcasts, talks, Stack Overflow comments, etc. The Chrome thing simply encouraged us to make it an official position.
Yes, thank you! I've seen this before and forgot. Looks like it's at Stage 2 right now, so still a ways to go until shipping, but should resolve all my gripes when it does.
- 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! :)