The wasm runtime wars are heating up! Exciting times :)<p>Really pumped to see this open sourced. And the performance properties look awesome.<p>One interesting thing we’re seeing in this space is sort of two parallel paths emerge: do you want to support JavaScript, or not? An example of the former is CloudFlare and their Workers platform. Hopefully they’ll follow Fastly’s lead and open source their runtime too, but it’s built on top of V8 because they want to support JavaScript. You also gain the additional advantage of all the engineering that Google puts into V8.<p>The other option is stuff like Lucent, wasmer, and wasmtime. By dropping the JavaScript requirement, you can build something that really screams, as seen here. You can partially regain <i>some</i> support via AssemblyScript, the TypeScript subset that compiles to JS. But we haven’t seen JavaScript compile directly to wasm yet because if you want that, well, V8 exists. And you do have to build it all yourself.<p>JavaScript is one of most popular programming programming languages that exists. Time will tell which approach is better, but it’s really fun to watch all of this cool technology explode onto the scene right now.<p>(Disclaimer: I have connections to all of these projects in various ways. Everyone involved in all of them is doing great work.)
Now that I see this, a question comes to mind: Why do we have yet another VM? Why didn't browsers just implement LLVM? Is it the sandbox?<p>Don't get me wrong, I'm excited to see wasm spread, but the question does cross my mind.
> With Lucet, Fastly’s edge cloud can execute tens of thousands of WebAssembly programs simultaneously, <i>in the same process</i>, without compromising security. [emphasis mine]<p>How does it handle Spectre, etc.?
Excited to see this come about and how it could be used with the OpenFaaS watchdog on Kubernetes. <a href="https://docs.openfaas.com/architecture/watchdog/" rel="nofollow">https://docs.openfaas.com/architecture/watchdog/</a> - is the 5 nano seconds the time to fork at the OS level or a kind of in-process hot performance?<p>I got an error with the example however.. is everyone else seeing the same thing?<p>Unpacking wasi-sdk (3.0) ...
Setting up wasi-sdk (3.0) ...
Removing intermediate container d552f4538e26
---> 713ff6032205
Step 8/8 : ENV WASI_SDK=/opt/wasi-sdk
---> Running in 4189f307a30e
Removing intermediate container 4189f307a30e
---> a142a5620a28
Successfully built a142a5620a28
Successfully tagged lucet-dev:latest
Lucet hasn't been installed yet... installing...
Creating a RELEASE build
cargo build --all --release --bins --lib
error: failed to read `/lucet/pwasm-validation/Cargo.toml`<p>Caused by:
No such file or directory (os error 2)
Makefile:11: recipe for target 'build' failed
make: <i></i>* [build] Error 101
Native WebAssembly sure is an exciting topic. But I can't think of a single concrete use case that someone could use---besides having another standard for secure bytecode to choose from. Help?
how does it look like this will work from a stack and a request/response flow perspective?<p>meaning, am I calling it as a function from within my vcl config? or am i mapping my service-id straight to a binary?
How does Lucet's WebAssembly performance compare to LuaJIT (one of the fastest JITs in existence) right now including VM warm-up time? Also, what's the GUI story like outside of browsers?