In general I think being able to run user-supplied code in a sandbox is the most interesting use-case for WASM and backends/Go.
Compiling entire applications to WASM and running them in a WASM runtime is of no interest to me. So for instance WASI isn't actually useful to me since I'd only want to project a very narrow set of APIs into the runtime for the (WASM) code to call. I certainly do not want to give it access to my system and then have to clamp down what access I give it.
I think what the original post points to is an interesting step in the right direction. If someone were to figure out an ergonomic and safe way to support structs, []byte slices as both parameters and return values that would probably open up a lot of new possibilities by lowering the barriers for adoption. If it is Go specific, I can live with that. If it can be done in a manner that supports lots of other languages, that would be fantastic, but to me, right now, it isn't critical.
If it were up to me I'd say forget about WASI for now and solve that problem instead. Yes WASI may be slightly useful some day (I can't see that I'll ever use it), but actually being able to have sandboxed runtimes where I can project in my APIs is vastly more useful.
(I'm not saying WASI is not useful. I'm saying that it is not useful to me. And I think that if projecting Go APIs into a sandbox is easy, then WASI probably isn't going to be important to most people doing backends as they can project more application specific, narrower and more strictly guarded APIs into the sandbox)
Given what you've just described, do you have an opinion on the component model & WIT[0]?
[0]: https://component-model.bytecodealliance.org/design/wit.html...
Using containers to run untrusted third party code is horribly risky. Containers provide nowhere nearly enough isolation and separation.
Anyway, points taken, thanks.
When working with backend systems you generally have 2 choices, a less secure containerized environment that does a very good job of distributing resources or a bulky VM which has a fixed memory cost that you might not need.
WASM sits right in the middle of the two. It has a durable sandbox that prevents bugs in the application logic from exposing the whole machine to exploit (and it itself can be further isolated using the same containerization security practices) but also has the benefits of single app like resource requirements.
Another prime benefit of WASM (not related to the sandboxing) is that WASM is a write once run anywhere standard. That means you don't need a different x86 and ARM wasm deployable. Similar to Java's JAR.
I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? This is clearly the direction in which it's all headed, yet is still mentioned relatively rarely in WASM-related discussions on here.