WebAssembly brings extensibility to network proxies | Hacker News Reader

WebAssembly brings extensibility to network proxies

opensource.googleblog.com

132 pointspjmlp19 comments

https://www.destroyallsoftware.com/talks/the-birth-and-death... I guess Gary was right. In other news, we have five years of war ahead of us.

So, Envoy will be embedding WebAssembly alongside (or instead of) Lua?

Are other projects moving from Lua (or other embedded scripting languages) to WebAssembly? What are the benefits of compiling an extension to WASM rather than writing it in Lua?

To me the big improvement over Lua won’t be security, or necessarily performance. It’s the ability to target a WASM runtime with your desired language, and it would still be a safe environment.

Be it Rust, C, C++, Typescript, and I bet there will be a Lua interpreter in WASM at some point too.

It will be more flexible, and possibly more performant.

I think the future is still hazy for managed languages, the GC side of Wasm is still in the design phase and it's not clear how widely it will be implemented. And it's been quiet for a long time, is the effor even alive? (https://github.com/WebAssembly/proposals/issues/16)

If it's going to encompass the possibility to hook into the JS side GC engine, this might not be implemented at all in headless Wasm applications, and so you wouldn't be able to use the GC'd languages on those platforms, just C(++)/Rust. Which is not very attractive compared to the easier / safer high level languages most programmers are used to.

You’re right. I should have said AssemblyScript, not TypeScript.

Also, As someone familiar with Rust, it is a very high-level language. It’s zero-overhead features make it a bit of a steep learning curve, but you rarely need to drop to its low-level unsafe features.

That being said, incorporating it into a new WASM environment probably means doing a lot of low-level stuff.

You can use GC languages. One of them is Go. WASM support is pretty good though direct dom access or some well tested wrappers would make it even better.

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.

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.

Sounds like a good idea to me -- just having more languages available for people to write extensions in sounds like a huge win.

What is the state of the art for WASM VM scripting? Adding Lua to a C program requires very little effort. Is the same true of WASM? What is the best “drop in” WASM VM for C programming?

I've recently been working on WASM VM embedding with C (well, via libffi) for a personal project and uncovered a couple of WASM VM options, wasmtime & wasmer:

* https://github.com/bytecodealliance/wasmtime

* https://wasmerio.github.io/wasmer/c/runtime-c-api/

The underlying implementation of each is written in Rust.

(Recently I also discovered there's a "micro VM" too: https://github.com/bytecodealliance/wasm-micro-runtime)

The official WASM C API is still WIP but wasmtime targets it directly: https://github.com/WebAssembly/wasm-c-api/

Not sure if Wasmer is aiming for compatibility with the official WASM C API currently.

From my experience, Wasmtime's C support is probably best described as "under-documented but functioning".

I haven't implemented anything with Wasmer.

My impression is that Wasmer may offer a higher level API than Wasmtime but not sure if it counts as "drop in" yet.

Part of the reason why I ended up going with Wasmtime was...I kinda forgot Wasmer existed. :D But also I do like that they're targeting what will hopefully become a standard API--but I think that results in a lower level API than what is most "friendly" for starting out.

Been meaning to make this embedded Wasmtime C API example--created while figuring things out--public after tidying it up a bit more but... well, I just now made it public, as is (it at least has a ReadMe now :D ): https://gitlab.com/RancidBacon/wasm-embed-test :)

Also, this is one option for test compiling C to WASM without setting up a tool chain: https://wasdk.github.io/WasmFiddle/

Some of my notes from development so far: http://www.labradoc.com/i/follower/p/notes-webassembly#20200...

Edit: Grammar. Add & then move micro WASM VM link.

Thanks for all the info! Looks like I've got some Sunday reading. :)

FWIW, Ethereum WASM (ewasm) has a cost (in "particles" ("gas")) for each WebAssembly opcode. [1]

Opcode costs help to incentivize efficient code.

ewasm/design /README.md [2] links to the complete WebAssembly instruction set. [3]

[1] https://ewasm.readthedocs.io/en/mkdocs/determining_wasm_gas_...

[2] https://github.com/ewasm/design/blob/master/README.md

[3] https://webassembly.github.io/spec/core/appendix/index-instr...

Reply on news.ycombinator.com