Hacker News new | ask | show | jobs
by danielheath 2290 days ago
The obvious benefits (to me) are performance and security.

Performance: Other than the need for trampolines between the host and the wasm code, WebAssembly runs at essentially full speed. Lua is fast for an language built on dynamic types and dynamic dispatch - which is to say, quite slow.

Security: The reference Lua implementation was not designed for untrusted code; there have been various attacks where loading invalid bytecode could grant arbitrary execution. Using a format designed for executing untrusted code has real advantages there.

5 comments

Isn’t the performance claim a bit of a misconception?

Lua with JIT is very fast even compared to statically typed, compiled languages.

The bottleneck doesn’t seem to be dynamic types or dispatch but rather relying on garbage collection. Another example of this would be Julia.

Admittedly WASM is typically targeted by languages like C and Rust, but I wouldn’t put Lua in the same, general performance category as for example python or most other dynamically typed languages with dynamic dispatch.

The cost of interop in WASM is currently very big as there's no way to pass non-numeric data to the host language without explicit conversion, which is very slow. WASI is trying to address this but as far as I know it's very far from being used by WASM language implementations. Most WASM implementations , by the way, are completely experimental at this point... listing 30 languages as supporting WASM seems highly misleading to me, as someone who has played around with a few languages compiling to WASM. I would say that only C, C++ and Rust have decent support. Even the Go support is currently extremely experimental and limited when compiling to WASM, and that would be the next "best" option. Lack of GC is a huge problem here and the current approach seems to be to allow runtimes to only optionally provide one.
No one is using the Lua reference implementation when performance is required. I haven't used Lua(JIT) for years, but when I did, its performance was approaching C-compiler in some cases. Although a tracing JIT does have its weaknesses as well.
I think all your points are more wrong than right since you pick the weakest possible constructions to attack (reference Lua implementation, invalid bytecode) and seem not to be aware of how good LuaJIT is performance-wise.
WebAssembly is slower than native too, how does it currently compare to Lua with a comparably safe & high level language?
Here an emulator author benchmarks Wasm implementation against JavaScript and Closure (2018).

Wasm is 1.5x - 11x faster depending on a browser and such.

Here is a very technical 2019 paper comparing Wasm against native compilation. Wasm is 1.5x slower than bare metal https://www.usenix.org/system/files/atc19-jangda.pdf

I think the first link is missing? But emulators are pretty unrepresentative for this use case and they're often written in low-level & unsafe languages.

The second is about benchmarking C, I suspect it doesn't give us a lot of information in this question either.