| > But I've always gotten confused with... it is secure because by default it can't do much. Yes. That’s a super accurate description. You’re not confused. > I don't quite understand how to view WebAssembly. You write in one language, it compiles things like basic math (nothing with network or filesystem) to another and it runs in an interpreter. Almost. Wasm is cheap to JIT compile and the resulting code is usually super efficient. Sometimes parity with native execution. > I feel like I have a severe lack/misunderstanding. There's a ton of hype for years, lots of investment... but it isn't like any case where you want to add Lua to an app you can add WebAssembly/vice versa? It’s definitely a case where the investment:utility ratio is high. ;-) Here’s the trade off between embedding Lua and embedding Wasm: - Both have the problem that they are only as secure as the API you expose to the guest program. If you expose `rm -rf /` to either Lua or Wasm, you’ll have a bad time. And it’s surprisingly difficult to convince yourself that you didn’t accidentally do that. Security is hard. - Wasm is faster than Lua. - Lua is a language for humans, no need for another language and compiler. That makes Lua a more natural choice for embedded scripting. - Lua is object oriented, garbage collected, and has a very principled story for how that gets exposed to the host in a safe way. Wasm source languages are usually not GC’d. That means that if you want to expose object oriented API to the guest program, then it’ll feel more natural to do that with Lua. - The wasm security model is dead simple and doesn’t (necessarily) rely on anything like GC, making it easier to convince yourself that the wasm implementation is free of security vulnerabilities. If you want a sandboxed execution environment then Wasm is better for that reason. |