Re:FaaS in Go with WASM, WASI and Rust
by klabb3 on Sunday May 07, 2023 @01:15AM
(#35848142)
FaaS is cool, but what I would love is if wasm can be used as a universal FFI boundary. Excellent tooling permitting, you could basically bring in dependencies from other language ecosystems when necessary. They could also be fully sandboxed.
[ Parent
| on HN ]
This is where it is going, checkout the component model https://cosmonic.com/blog/engineering/evolution-of-wasm-stan...
The problem with this is that memory management across subsystem boundaries is very difficult.
Re:FaaS in Go with WASM, WASI and Rust
by brodouevencode on Sunday May 07, 2023 @09:37AM
(#35851407)
I think that’s what OP meant by tooling permitting.
Truffle is that but better.
Re:FaaS in Go with WASM, WASI and Rust
by adrianfcole on Sunday May 07, 2023 @07:37PM
(#35856631)
(wazero maintainer) Right now, there's no auto-magic repackaging, but it is extremely common to do manually in our ecosystem. Most will use go:embed to embed the wasm binary into the compiled application so it still appears all static linked, self contained at the end.
A couple examples of this: * https://github.com/jerbob92/go-pdfium-wasm * https://github.com/ncruces/go-sqlite3
More here: https://wazero.io/community/users/
Note that often times a lot of work is porting because not all tools build well to wasm. This would apply for any runtime as we're just running the standard with some special extensions for emscripten, wasi etc.
We’re trying to get close to this, via our Universal Plugin System, Extism: https://github.com/extism/extism
Call common wasm code across 16 different programming languages using our SDKs.